Web Inaccessibility — Are Missing, Muddle Use Cases the Culprit?

Web Inaccessibility — Are Missing, Muddle Use Cases the Culprit?

As I have been learning to traverse websites using the nvda screen reader (previous post) I try to formulate the principles of design and implementation that make this task more or less productive, as well as pleasurable. At the same time, I have been tutoring myself in the accessibility literature, mostly in the form of blogs and podcasts. This post recounts some of my frustrations, diagnoses possible remedies, and a sweeping conjecture about the root cause of much web inaccessibility and difficult usability.

As I improve my proficiency with the nvda screen reader and learn to navigate web sites by voice and keyboard, I am constantly amazed at how hard it can be to get where you want to go and avoid heading down the many, well, blind alleys. I am an Internet veteran: first email around 1976, worked with protocol pioneer Jon Postel, saw Mosaic in late 1992, had my first web page in 1993, set up my first domain name and website in 1995, and several websites since, plus writing search analysis software, Java applets used around the world for security training, and a podcatcher for partially sighted people like me. However, all too often, I find myself fumbling, stumbling, and cursing my way around websites, wondering why using a browser with a screen reader is so difficult, error prone, and exhausting. Is it the tools I am using? or my admitted status as self-trained beginner in the low vision world? ignorant of accessibility tricks and techniques? or maybe I expect the task to be easier than possible, for me or others?

To document my environment: Windows XP on tablet PCs, Mozilla Firefox browser used for over 3 years, TextAloud toolbar for reading and zooming on pages, nvda screen reader used for 2 months as discussed in previous post, responsive natural synthetic voices, pretty good bandwidth on home wireless and cable. My main browser interactions: h for heading to page sections; k to links; control F for quick find page search; tab among page items; up and down arrows through lines; page up up, down, home, and end to page boundaries; INS + down to read consecutively down a page; INS + BLANK to pass through typing into form fields; control K to start a search; control L to open a new site.

Here are a few situations, complaints, diagnoses, and remedies.

Booking a flight on USAir, fondly known in Arizona as America West. I cannot find the boxes to query for flight schedules then make a choice and book the flight. So I reluctantly call the 800 number, beg my way out of the $10 booking penalty, and hope for a good fare. The problem in software design terms is that USAIR has scrambled its use cases together on the first page, providing last minute specials, detours to frequent flier data, wonderful offers of cruises and vacations, and practically everything the airline does. On a good sight day, I can locate the depart/arrive boxes to start, but screenless. Like many commercial booking websites, I give a rating of “hopeless jumble of links” although the sites may still conform to the letter of accessibility rules.

Amazon has also seemed like another jumble of links: recommendations, my account, searches for all kinds of items, invitations to become a seller. But, thankfully, there is a link to a more accessible streamlined page I can actually use most of the time. It is ironic that the needs for mobile users to see small screens coincides with the needs of visually impaired users to traverse streamlined web pages. This allows me to get most of a pre-defined purchase completed, going into exploration and recommendation mode when I choose rather than as obstacles on the route to a purchase. I still need sighted help to get the coupon numbers copied onto the purchase page, but transaction appear less daunting now on Amazon. Actually, on return recently, the website appears to be undergoing a makeover from accessibility experts – kudos to them!

Hurrah!! it is so exhilarating to see a simple page show up, just like the early days of the web, before images, adsense, navigation bars, dynamic content, etc. So, here is a remedy when doing battle with a complex commercial site: Look for a “basic HTML”, “mobile friendly”, “mobile optimized” link and throw back to the early days of the web. Thanks to Allison Sheridan for urging me in this direction on her vision-friendly NoscillaCast podcast.

How about search sites? Well, google is pretty good at separating its search results with headings with intervening links to google alternatives, including the extremely valuable “view as HTML” that avoids a cycle of save, import, export as text, and listen rather than open the usually unneeded Microsoft Word and Adobe PDF. On the other hand, the tagged and search-based gmail is a tangled overlay of use cases. For example, archiving messages by a filter requiring several steps down to a filter label, over to a select all link click, combo pull down to Archive list item, and return to Inbox. In single step mode,, one can check the box for conversations the find the archive button. Or there are keyboard shortcuts that my mind simply boggles at learning. At least reading gmail is enabled by a pop3 account on my Icon or, soon to be, fully voiced Mozilla Thunderbird. Google offers a separate search that weights accessibility into its search results, but I have not used it sufficiently to comment.

Blog readability varies a lot, but at least there is a common structure: entries with associated reply and comment fields; archives; blogrolls of links; and assorted meta data and added pages. The clincher is choice of template to place navigation bars relative to blog entries — right and below being best for screen readers and spoken RSS clients. While not easy, the wordpress dashboard is usable through a combination of good structure and parsimonious informative link labels.

Government Web Sites often, while conform ant with the so-called 508 mandate, follow a recognizable organizational or legislative hierarchy, sometimes with a touch of hilarity. I’m familiar with the NSF Fastlane proposal management system, which has changed little in the past 5 years except for an accretion of bureaucratic guano. It took me 17 tabs to get to the login box on one page, covering links about travel, registration, policies here, manuals there when the sole purpose most users would be on this page was to enter username then password. Later I found myself scrolling over a large block of text to the worksheet, a rendition of workload requirements that nobody in their right mind would read except for a hapless blind person who got stuck there. My complaints to a government representative were duly noted and agreed with but it will take a very fresh perspective to turn a bureaucratic haystack into a really usable website, well beyond the purview of accessibility standards that may simply divert attention to the wrong details.

I was highly impressed recently on the medicare.gov website when a link came up for screen readers. Following that path, I soon ran into the hilariously dumb “Click here” link text that should be a red flag for any accessibility analysis clickhere for what? And there was a sequence of “click here” on a page expressly designed for screen readers! Geez, where are the accessibility police?

Well, that’s enough complains, what does the literature of accessibility tell us? First, there are the common sense guidelines, see links below, that mention the sensible ordering, link text, graphic ALT tags, use of headings to reveal page structure. Any trip into the standards literature shows how complex the language and tradeoffs are, when compiled by a group of experts trying to reach a consensus — not an easy read for anybody, and a good excuse for routine web designers to avoid thinking about accessibility. The standout book for me is “Constructing Accessible Websites” which tours the landscape of HTML and CSS as well as the legal issues, e.g. can that routine web designer be held accountable for violating ADA laws?

Blogs such as “A List Apart”, WebAxe, WebAim, etc. often delve into highly technical issues of web accessibility at a feature and technology level. The tradeoffs of writing a web page one way or another are often poorly understood and tricky to articulate so the expense of apaplying a particular rule can be hard to justify. Indeed, my technical background combined with my accessibility needs leads me to commiserate with people who must deal with accessibility, especially late in website design or even later in mintenance, violating the software process rule that cost escalates with delay in addressing a solid requirement.

I have been confusing two terms here, “accessibility” and “usability”, with the latter my main concern. Accessibility is more technical in stipulating that the system stack of hardware, operating system, applications, and screen display provide sufficient and correct information about the screen data state and events to screen readers to interpret and pass onto uers. This architecture is historical and, I believe, wrong to its core now that we have a “speech channel” that could throw the responsibility for interpretation and amplification of data provided to bypass or supplement the screen reader ,, but that’s a future posting. Usability refers to the bottom line of whether users can complete the tasks at hand. Inaccessible features here and there may be barriers to usability but issues of separation of content and presentation, well-planned navigation, and display of the right stuff at the right time most determine usability.

For this Vision Loser, there is an internal batter reading of energy consumed by tasks, enabling me t to predict impossible tasks and schedule smaller chunks of work that can be completed. We have noted in our post on “Extreme Voting” that voting tasks fall in the range of Olympic events which must be completed under severe time constraints with no prior training or practice, complicated further by long ballots. To sighted people open to a comparable challenge: use a talking ATM to withdraw $100 in less than 1 minute.

A few conclusions are:

  • The book “Constructing Web Accessibility” validates my navigation complaints as common and often cured by “link to content”, “jump to sidebar”, modest sized navigation bars, supers mart screen readers able to recognize chunks of HTML as non-content to bypass, and and avoiding the pernicious dumb “click here” or “learn more” link. These are sign posts of attention of web site designers toward accessibility and techniques to improve my browsing practice.
  • Indeed, I am not fully empowered by my chosen screen reader to jump comfortably to all parts of a pages I will wait for the next version, partially developed under a Mozilla grant, to determine whether this youthful product is remiss and watch carefully for the productivity improvements noted above. Meantime, I can live with excess links as long as I know where I am situated on a page, e.g. by a “heading tour”.
  • I just can’t help but reverse engineer each transactional website into its use cases and mentally Write an introduction I wish were available as a spoken site overview.
  • The trend toward mobile pages offers a practical remedy for working on many websites, with hope for momentum to alter web design.

So, what is the big deal with “use cases”? The sweeping conclusion.

The concept is quite simple: a system’s design starts, in part, from a suite of named paths through the system’s eventual operations interleaved with those of users and other systems. Each use case has a precondition for its proper execution, a post condition stating the changes and outputs, and considerations of errors and options. In practice, a use case analysis can take several weeks and result in multiple pages of structured text and graphics, sometimes produced by CASE computer-assisted software engineering tools. This kind of stuff is taught presently in software engineering and object-oriented design analysis courses.

My complaint is that these use cases, whether explicit or not, are then mapped into a few web pages with forms, combo boxes, and text labels. The situation is close to what we called in the 1970s “spaghetti code” where control flow was woven through small sections of code because the state of programming languages did not sufficiently support modularity or the world view of object orientation. HTML is the assembly language that is unfortunately available to thousands of web designers not educated in the more advanced methodology and tool base that systematized programming to some extent.

The sighted person has an intuitive grasp of what each form needs and the physical agility to complete it and to detect and correct mistakes. The visually impaired person must somehow parse how the use cases, find the appropriate forms, meet the unidentified preconditions, find error message and fault locations, avoid cancel buttons, and complete the task before a time-out, wireless failure, or automatic PC update invalidates minutes, or hours, of tedious work.

Note again how nicely the “mobile revolution” can cooperate with accessibility. A site developer must identify the most important use cases to place on a mobile-friendly page, strip off ads and special offers, put the function forms prominent, and not clutter the page with navigation. That busy traveler needing to order a gadget without recommendation use cases, frequent purchaser signups, and the latest added options’ — and so does the visually impaired user. Separate and save the recommendations, special offer shopping, and account management until the transaction is completed or for idle browsing moments.

Looking back at our examples: a flight schedule lookup should not be cluttered by cruise offers; a log-on to enter a review system should not be over-run with travel instructions; a workload policy is worth no more than a link off a worksheet page, at worst at the bottom; navigation bars aren’t relevant to most use cases; and a mail archive is a lot different than an email lookup. Accessibility writings warn of the difficulties presented by mixing presentation with structured content, e.g. omitting headings. An insidious practice seems to be the desire to make all use cases available on a single page. This is a weird form of optimization I wish someone could explain to me. Is this optimization a root cause of broken rules of accessibility, poor structure, an insurmountable challenge to screen readers, and a constant pain to visually impaired users?

Not surprisingly, a search on terms “use cases and assistive technology” or “use cases web page accessibility” shows some interest in this topic in the w3c and usability communities. My epiphany for my own learning and continued improvement in web skills is that it helps to construct a mental map of the use cases and how they are implemented in the navigation and interaction items of a website, whether on a single page or across a site. My wish is that web page designers would present an overview of their web site in use case terms. In the longer term, it would be great to have multiple presentations, such as the trend toward mobile-friendly pages, where the use cases are sufficiently separated into separate pages that the mental load of intuiting and remembering the use cases becomes less critical to successful use of their sites.

Recently, I ran across JumpChart, a web page design tool that supports what usability people call a wire frame. This tool is exactly the place to interject both accessibility concerns and mechanisms for supporting accessibility.

Wow, is there a lot of substance to this topic. I hope soon to find counter-example websites to the troubles I attribute to missing and muddled use cases, as well as highly accessible pages in the technical and usability sense. Finally, my own mea culpa for all the stupid stuff I have dropped onto websites and made usability harder — I am working to correct my bad style. I haven’t addressed the Target lawsuit or capcha or other biases and so much more is known about hacks and techniques for accessibility. See our podcast library for hours of informative listening.


  1. Guidelines for 508 government website mandate
  2. Recommendations for accessibility from MIT
  3. Amazon entry and reviews of “Constructing Accessible Website” book and “Constructing accessible websites also available from Bookshare
  4. accessibility consulting and resources from Jim Thatcher
  5. Webaxe accessibility tips and podcast
  6. <a href=”http://en.wikipedia.org/wiki/Use_case&#8221;?Wikipedia article on “use cases”
  7. ` WebAIM blog roundup of blogs on accessibility

  8. JumpChart web design service
  9. nvda, nonVisual Desktop Access free, open source screen reader
  10. apodder.org podcast library on “web accessibility”, collected by @Podder podcatcher

Tags: , ,

3 Responses to “Web Inaccessibility — Are Missing, Muddle Use Cases the Culprit?”

  1. Hear me stumble — web accessibility observations « As Your World Changes Says:

    […] Previous posting: “are Missing, Muddle Use cases the cause of much web inaccessibility […]

  2. Is there a Killer App for Accessibility? « As Your World Changes Says:

    […] have argued in “Are missing, muddled use cases the cause of web inaccessibility?” posting that the main culprit in web usability is not technical accessibility but the way use cases are […]

  3. Webliography for ‘Grafting Accessibility onto Computer Science Education’ « As Your World Changes Says:

    […] AYWC Are missing, muddled use cases the cause of inaccessibility? […]

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: