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
- WAI-aria proposals for accessible-rich web next generation technologies;
- webaxe accessibility blog for typical accessibility engineering principles;
- SXSW Interactive Media conference presentation’ on accessibility issues and enterprise approaches
- Previous posting: “are Missing, Muddle Use cases the cause of much web inaccessibility
recurring Problems that are easily fixed
- 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 .
- 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.
- 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?
- 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
- 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 world.org, 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.
- 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 amazon.com with accessible, mobile amazon.com . 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.
- 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.
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.