Roles in Accessibility

Mon, 18 May, 2009

Posted by Katherine at 21:22

A gear is a component within a transmission device that transmits rotational force to another gear or device. A gear is different from a pulley in that a gear is a round wheel that has linkages ("teeth" or "cogs") that mesh with other gear teeth, allowing force to be fully transferred without slippage. Depending on their construction and arrangement, geared devices can transmit forces at different speeds, torques, or in a different direction, from the power source.

(Thanks, Wikipedia.)

Been doing some research recently regarding components of web accessibility. For a site, a page, an app to be fully accessible, it takes cooperation in several relationships between components.

As the Web Accessibility Initiative (or WAI) puts it, components to make the web accessible are defined as follows:

content
- This would be the literal content (words and information) of the page or app, but also includes the code that presents the information
user agents
- A fancy thing to call browsers, app launchers, media players, and other platforms.
assistive technologies
- I interpret these to be user agents with accessibility foremost in mind. This includes, obviously, screen readers and magnifiers, but also equipment such as alternative keyboards (utilizing pedals, sip-and-puff interfaces, head wands, etc) and browser extensions (like the Accessibility extension in FF). While these are technically user agents or some facet of them, they are categorized separately so that their support of accessibility features is maintained separately.
users
- Not just the guy behind the keyboard either. The "users" component here encompasses users interaction with the page or app, their thought processes and background knowledge as it relates to the web technology and the information they are accessing, the ways in which they work around their personal accessibility problems on any given page or app, and their past experience and expertise level with the web and web technologies.
developers
- In this case, the term refers to every person who builds a page, including the programmers, designers, content authors, and feedback-contributors.
authoring tools
- These refer to WYSIWYG editors like Dreamweaver and Contribute, as well as CMSs like Drupal (yay!), and blogging software like Blogger, Wordpress (also yay), etc.
evaluation tools
- These guys don't really play a huge part in everyone's role in page creation and use, but their part is pretty useful. These include HTML and CSS validators, implemented to see if a page's markup is valid by W3C markup standards.

A big thing to keep in mind with each of these components is that each one interacts with the others in a complex and integral way to create an accessible user experience for everyone. The developers use the authoring tools to make content, testing it with evaluation tools before releasing them to the users, who access the content through user agents with assistive technologies as needed.

As such, if one of these components ignores an accessibility feature, it is likely that the others will at best hit a snag in this area or at worst, follow suit.

Let's take, for example, the "abbr" HTML tag. The idea of this tag is to provide understanding of what a certain abbreviation means. For example:

the <abbr title="Content Construction Kit">CCK</a> module in Drupal

For sighted users, the advantage of the "abbr" tag comes when the cursor hovers over it, causing the expanded title to appear. This is great to clear up confusion for sighted readers, however, what about users with limited or no vision?

A November 2008 study showed that the screen reader JAWS, versions 7.10 and 8, both had issues with rendering abbreviations. For the most part, it just ignored them. As, it seems, did Thunder. This was a problem when presenting the electronic text auditorily, because, well, read that phrase aloud and try to pronounce CCK as if it was a word. You'll sound like a cat with a hairball, as will one of those screen readers. A tip that was passed around was for users relying on the screen reader to use the "Spell Word" command in JAWS, forcing the screen reader to simply pronounce each letter in the abbreviation/acronym. Still doesn't give the user the information, but at least it's not incoherent.

Likewise, Internet Explorer 6 and earlier did not support this tag and just wouldn't render it (Internet Explorer 7 has since begun supporting it). This tag's neglect continues in such WYSIWYG authoring tools as FCK Editor and some blogging WYSIWYG editors.

This is a small example of a bigger point. If one component in the usability process ignores an accessibility feature, it leads other components to neglect it as well. If many browsers don't implement a feature consistently, there is little motivation for developers to care about putting it into their code. If it's not easily implemented by an authoring tool, there is little chance that a content writer is going to kill himself to get it onto the page. This leads to poor solutions, such as the "Spell Word" workaround, or developers hand-coding accessibility features into their markup.

At the end of the day, these workarounds help no one. They don't fix, they delay. They make it easier for the humans involved to believe that this feature of accessibility is not crucial to integrate fully into the accessibility process because hey, there's already something out there for it. And I'm not pointing any fingers; I have been just as guilty of this as anyone. But I aim to change this fact for everyone involved.

This does not make you a negligent developer or content writer. Not at all! What it means is that we as developers must be aware of which components we have influence over in the accessibility process, and use that influence as we can. If a popular browser or screen reader that many of your users rely on doesn't support something that you consider to be a crucial accessibility feature for your work, contact the developers of that agent and request it as a bug fix. If your authoring tool does not support an accessibility feature you need, try a new one and contact the people who work on its development. If you help develop one of these components (like oh say, Drupal or any of its many beautiful modules), be mindful of the accessibility requests that come your way. They might not be nearly as sexy as the requests for portability of your app to Ice Weasel on the iPhone, but they're far more crucial.

Ultimately, web accessibility is not a job to be taken care of by any one person. It is an ongoing process and we as developers share the responsibility.

If you read this whole entire rant/essay, congratulations, you get a cyber-cookie: