Thinking about Web accessibility, even as briefly as I have been, opens up a large chapter in my understanding of Web technology and how well or not well it is working for all of us. While many of us comment on what information overload is doing to our lives, there are many people for whom all that information would be incredibly useful if it weren’t for all the kinks in their information fire hose.
The Web Accessibility In Mind (WebAIM.org) survey provides an interesting overview of the issues and some of the difficulty in addressing them. While accessibility standards are outlined with good clarity elsewhere (http://www.w3.org/TR/WCAG20/), things become less clear when examining the preferences of those they benefit. The clarity tends to break down between parts of the audience who are highly-proficient at screen reader use as opposed to less-proficient users, but sometimes, the reasons for diverging opinions were harder to name.
I was unaware until recently that when Using a screen reader that there is sometimes screen-reader specific content available. The WebAIM report notes that this content is widely preferred by screen reader users over accessing the text-only version of a Web site, when that option is also available. The WebAIM report suggests that this is due to the attractiveness of audience-specific content. It makes sense that an audience will appreciate and respond to content that is geared to them and presumably more useful to them. That is, after all, the focus of so much Web marketing. I am very curious to know the particulars of generating screen-reader specific content. One site I have run across that specifically addresses accessibility and includes at least one page describing some its accessibility features is Food Solutions New England.
I make increasing use of Web applications in the cloud. If asked how accessible these applications are, I would have agreed with those survey responders without disabilities in guessing that such applications are not accessible. Twenty-four percent of responders, however, answered that they are somewhat accessible. To me, this is a surprisingly large number. In this group were people with disabilities and Firefox users. The Firefox users had more favorable impressions, probably due to the Accessible Rich Internet Applications (ARIA) support of Firefox, as the report says. So this is encouraging to me, as I would have expected a much worse response to Web 2.0 usability.
I was also surprised by highly-proficient responders’ interest in reading the Alt tags for images that exist on a page for enhancement of the mood or feel of a Web page. Those with disabilities preferred that the image be described, which I think is great. As a designer, my own mental image of a page enhances my experience of it in many ways. Similarly, I think, users who are not able to see a page, can have a richer experience of it when it’s appearance is described, and their own mental image is enhanced. Again, there is a slight preference for this among the more skilled users of screen readers.
At first, I was a big fan of Flash, but I am now becoming more aware of the problems it poses on the Web — in this case, those are accessibility problems. I am much less a fan of Flash now than I have been in the past. It’s ubiquitousness and market-penetration is somewhat alarming, now, whereas it was appealing, before.
I am still fond of the PDF format. (See my earlier blog post.) It seems to have its accessibility issues, but the survey is not so clear on whether the PDF format is good or bad. I wonder if much of the PDF accessibility problems might stem from how the PDF was generated or the structure of the document it was generated from. I hope that the format can be improved upon, because it certainly has excellent applications.
The report notes that “The wide range of user responses makes it difficult to provide definitive recommendations for many things.” Although this may be the case for recommendations, the report still lends a lot of insight to user behavior with screen readers that a newbie graphic designer and Web developer like me can benefit from.
“I am very curious to know the particulars of generating screen-reader specific content.”
We’ll be touching upon this briefly when we do the tables and forms coding exercises. But until then you can do some exploring on your own by visiting sites that are (or claim to be) accessible and turn off the CSS and see if you see content that wasn’t on the page when the CSS was turned on. For example, you’ve already learned that skip navigation links are often hidden from view. (That’s fine for screen-reader users, but certainly not expecially helpful for non-mouse keyboard users!) But particularly well-done accessible sites will also provide descriptive headings just for screen-readers.
To see what I mean, go to http://html.cita.illinois.edu/text/test/test-ff-disablecss.php. You’ll notice the ‘standard’ breadcrumb navigation near the top… Now turn off the CSS and you’ll see the heading “Bread Crumbs.” We sighted users don’t need to be told it’s the breadcrumb nav, but a screen-reader user could easily be confused: are those links for the main nav or what? A particularly well-coded accessible site could even have headings such as “sidebar article” etc. to help describe the structure of a page to a screen-reader user. (Turn the CSS back on and use Firebug to examine the breadcrumb nav. You’ll see there is an H2 heading of Bread Crumbs, but the CSS pushes it 200ems off the left side of the screen. Therefore we don’t see it but the screen-reader does!)
Nice find with the Food Solutions New England site! It’s a good example of how the accessibility of a site can be graded on a continuum. It’s made good efforts toward achieving accessibility yet it fails on color contrast, and I for one don’t find the keyboard navigation to be particularly easy…
#
I *totally* rely upon Firebug on the job — that’s my #1 tool for diagnosing and trouble-shooting CSS problems. I would be severely handicapped without it.
The Royal National Institute of Blind People (http://www.rnib.org.uk/) uses skip nav links. You’ll see that the homepage only uses “skip to main content” while the interior pages also provide a “skip to section navigation.” Skip nav links allow the keyboard-only user a shortcut to jump immediately to links within the main content, for example, rather than have to tab through all the navigation links before getting to the main content. Similarly, a screen-reader user will hear these links shortly after the page is loaded, and provides them with the same opportunity to say “don’t bother me reading all the nav — just take me to the content.”
Some sites use skip nav links ONLY for the screen-reader user, so they’re not visible to a sighted keyboard-only user when first accessing the page. However, once that keyboard-only user starts tabbing through the site, they will see the skip links highlighted and then can use them….
About skip nav links: http://webaim.org/techniques/skipnav/
#