Posts Tagged ‘use cases’

Hear me stumble — web accessibility observations

March 16, 2008

This posting lists several good and bad examples of web accessibility and usability situations in an instructive sense, including recorded sessions of this intrepid logger guiding her web page readers.

Background Postings and Standards

recurring Problems that are easily fixed

  1. Problem: useless links click Here — huh, for what?

    The unfortunate user must expend extra energy to read surrounding context to find what the click is for. This mistake usually indicates poor communication skills and lack of testing using a screen reader. variations include: Learn More, read more, and the especially illuminating here. similarly, a document may be identified then followed by its type a line like PDF or HTML or size 5 MB.

    Recommendation: Page content writers should read out loud the list of links by screen reader or by eye scanning and assure clarity where each link leads. And there is no excuse for not using a screen reader with the nvda, free, open source, easily installed screen reader .

  2. Problem: blog postings blocked by links — when good blogs go bad.

    conventional web layouts contain site navigation, rolls of links to related content, meta data about site and author, news, etc. screen readers follow a left upper corner, top, left, order that forces reading or bypassing links to reach actual page content, which sighted readers look for in the middle of a page. a repeat visitor rarely has interest in these links. blog and other content management systems usually provide a choice of page layout Reading a links-first blog format takes up screen reader time, even with a jump to heading. More disastrously, an RSS client often receives all the links on a text version of a posting, taking a minute or more to read before content, making some blogs effectively unbearable in RSS format.

    Recommendation: Design pages and choose layouts to favor quick access to recurring content, placing honorific stuff right and below what your main page matter.

    Examples: two of my favorite tech blogs, Good example: Jon Udell blog and Bad example: Phil windley’s technometria.

  3. Problem: Learning the structure of a page — it’s the headings, stupid!

    we all know to sprinkle headings through our documents to break into and describe sections, even applying this to bills and forms. for a screen reader user, headings provide the primary way of moving among sections, often preceded by an exploratory “heading tour” to identify the page sections ahead. without sections, the screen reader’s finer detail units are links, lists, and paragraphs, but this rapidly degenerates into interminable tabs and keystrokes like taking steps into a cave without knowing where the path will lead. conversely, a well-sectioned document also broken into pages can be very rapidly browsed with a screen reader, perhaps even faster than a scrolling sighted reader. can cover graphics and font styles. Chunks of text can be skipped for more detailed reading later. Nothing substitutes for having a sense of the page’s structure in outline form.

    Recommendation: Make sure all page sections are well described by HTML H1, H2, H3,… headings with informative descriptions. Now, is that so hard?

    Examples Good example:”> program organized by days and topic and Good Example: browsing wai-aria documentation

  4. Problem: switchingfrom browser to an external app — .txt imprisoned in .doc or .pdf

    Browsers are now integrated with external applications like Microsoft word or adobe PDF. but that meanss a screen reader user must first launch that app, and, of course, MS OFFICE is not free! reading the document involves a different set of keystrokes and conventions with PDF often losing any previous document structure. Ironically, frequently, the document being read is little more than text any way! This vision Loser simply saves DOC or PDF and then strips the document down to TXT for reading in Notepad or on an external reader like APH Bookport or Levelstar Icon. With gratitude, another path is google search “View as HTML” and HTML save As in mobile gmail. This argument also applies to mail attachment — imprisoning text memos in a WORD format attachment requires a lot of extra work by a visually impaired recipient, and “click on attachment” is often a security risk.

    Recommendation: Web authors should save a version of a document as HTML and Make that a primary link, offering a PDF for portability (that’s the P in PDF). HTML is the document format that literate web writers should be using, e.g. to exploit hyperlinks, and not at all the private domain of web designers and New Media or IT departments. Strictly speaking any PDF should be produced in accessible format for extensive reading.

More complicated web accessibility Problems

  1. Problem: Locked out of the chat room — social Media Overkill.

    recently, one of my favorite podcasters started live chat sessions with call-in. I wanted to ask a question and join in so showed up at the web page at the appointed time, having pre-registered and browsed the site the day before. Uh, oh, I couldn’t find an entry point, didn’t even know what I was looking for. worse yet, an audio had started playing – was that the current session? No, it was prerecorded, drowning out my screen reader with no way of silencing the cacophony. Eventually I waded through a ton of links to other shows, popular podcasters, special offers and found a PLAY button. Now, all this with a screen reader contending with an audio discussion, and then the text chat was completely inaccessible to the screen reader. well, that podcaster lost a fan’s admiration for choosing BlogTalkRadion as a meeting place uncomfortable for me. The key problem was that the main purpose — to bring people together — was obscured by the now socially acceptable business practice of trying to draw attention to other podcasts and \shows – current, popular, categories, rated, which we term “social media over-kill”.
    The irony is that the blind and visually impaired communities have superior chat facilities, as exemplified by accessible, built on Talking communities supporting happily chatting friends of Bookshare book club meetings.

    Recommendation: when choosing a hosting service, check out its accessibility policy, not just how free it might be, if you want to retain your whole audience and its respect. service providers, please write and follow an accessibility policy and stress its use to service users. service providers, content management system designers, and designer assistants all have a great social responsibility – and opportunity – to be inclusive and to educate service users.

  2. Problem: Muddled, missing, mixed use cases — accessibility and mobility needs are met together.

    consider if you know exactly the book you want to buy at amazon or another big web seller. a trip into amazon takes you through myriad departments of other types of products, offers Recommendations, specials, bundles, and even a chance to become a reseller yourself. but all I wanted to do was get that one book into my cart! Well, luckily, limited screen space on phones and PDA’s is leading to overhauls of web sites to alternatives that offer simple and straight paths to the most common goals for impatient, on-the-go users. contrast clutter full scale with accessible, mobile . Now, not all of Amazon is on the accessible alternative, and they don’t tell you what’s missing, e.g. changing an e-mail address in profile.

    Recommendation: web designers can take the opportunity to produce an accessible version of a site along with a mobile-friendly or mobile-optimized version. and don’t forget to tell screen reader users with a non-intrusive link at the top of the page to the alternative. and, save the specials and Recommendations until after the sale.

  3. Problem: forms take forever to fill out and an error can be costly, causing form-o-phobia.

    It’s not just me, the usability literature notes something like 5 times longer for visually impaired form-fillers than sighted users. problems include: identifying required versus optional and what actually goes in a field; non-standard formats for dates, social security numbers, phone numbers; unpredictability of length of forms; time-outs and site failures; and difficulty finding the notification of errors or requirements for verifications. Then there are all those registration “opportunities”, without explanation of benefits of registering, without acknowledgment of the pain to be incurred. No thanks, no forms please.
    Is there a better way? Maybe, as suggested by Jon Udell’s article on batch form-filling for civilians suggesting the use of text strings completed by simple editing and input to an API or query processor. geez, this is so brilliant!

    Recommendation: web designers should take every care to label all fields clearly and acknowledge the time and pain of a visually impaired user. If possible, watch one of us use your form until you cannot stand the pain any longer. and recognize the difference in skill levels and experience and tenacity of a broad audience. forms are where you capture or lose a client. and, don’t even think of putting a graphic only CAPTCHA at the end at risk of eternal damnation. On the other side, visually impaired users need to practice form-filling and accept it as a necessary evil that could ruin your day. We all need to look for better ways, like Jon Udell’s text line suggestion.

Personal Observations and Grand Claims

With a year’s experience using a screen reader, I am still a novice and use articles like this to apportion responsibility for failures
to accomplish web tasks. With a 4-decade career in computing paralleling the lifetime of the Internet, I am acutely aware of many sources of failures: selection, training, and skill level with software, like browsers and screen readers; network and workstation architectures that dictate performance; application requirements analysis and design, as in web 2.0 interactions; educational backgrounds and career motivations of web designers; human proclivity toward ascribing beauty to color and graphics I can no longer appreciate; the levels of personal, team, and enterprise processes that influence application usability; the immense costs of maintenance and upgrade of web sites; and now, the structure of the assistive technology industry, the many human factors of accessibility, and the social resistance to disability issues. Mainly I am trying to take responsibility for building my skills to remain productive in society, and especially to pass along technology lessons to other Vision Losers.

Rarely am I completely stymied but far too often the energy required is the limiting factor. I use the “minimum of 5 times ” rule to estimate effort required for a task, based on memory of past trials. Often, just the thought of the work involved deters me from trying a web site, like registering and then facing a CAPTCHA, maybe putting off to a future idle day. Flippantly, I wish all young web designers would test their web sites during a bout with the flu, so they might appreciate the effects of reduced energy on every click and key stroke.

A second observation is how much the web is overly populated with extremely complex web sites, exacerbated by the trend to social media linking. Every link bypassed in a blog or information page is a decrement in energy available for reading, navigating, information seeking, and transactions. Web designers often seem to cram too many functions onto pages and fail to identify the primary use cases and prioritize for screen reader users. I am delighted at the trend toward mobile friendly pages as very helpful in countering complexity and offering redesign opportunities.

In recent discussions with web accessibility practitioners I sometimes found myself thinking as the beggarly, or maybe miserly,old lady who could not shell out $1000 for an industry standard screen reader like Jaws or Window Eyes and got stuck with a third world open source software tool. There is some truth in the monetary argument as I fail to fall into the social services classes: veteran, worker, job seeker, student, or poverty level. But I have also made a technical choice in screen reader, nvda, based on confidence in its developers, satisfaction with its early capabilities, ease of use and installation, and belief in the efficacy of the open source model of development. I also am concerned at a shaky industry chain of developers, screen reader vendors, and rehab organizations that will soon be coming under more international pressure as a free screen reader takes hold in other countries, perhaps with easy adaptability for local languages and web conventions. I cheer for the Australian Torvalds of assistive technology.

Finally, I find myself moving away from the PC and browser with increasing use of the Levelstar Icon PDA. News comes from the NFB News line to Bookshare to the Icon’s Newstand without a visit to a slow web site. Blogs and feeds bring more news from CNN, USAToday, CNET, and many political and professional organizations — again obviating a browser session in favor of RSS. And the Icon’s little browser often suffices for comfortably reading search results, pages, and blogs not embroiled in JavaScript/AJAX interfaces.

Ok, hear me stumble! Listen to recorded sessions.

Here are two recorded sessions of screen reader uses at Amazon and Fidelity. The Amazon demo follows me through the process of getting a pre-selected book into the cart, using the newer accessible and the classic web sites. The Fidelity example shows an exploration of a web site that has its whole enterprise mapped into menus.

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

November 14, 2007

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 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=”;?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. podcast library on “web accessibility”, collected by @Podder podcatcher