Emily P. Lewis | June 15, 2010
There isn’t a lot of data currently available that quantifies how many websites today are truly accessible. There have been some reports, however, that suggest the percentage of inaccessible web sites is alarmingly high. I’ve even seen figures as high as 81 percent. And these aren’t global figures.
What does seem to be clear, though, is the culprit behind this inaccessibility: a lack of understanding about the importance of accessibility, as well as a lack of knowledge about how to implement accessibility guidelines. Yet, according to A List Apart’s 2008 Survey for People Who Make Websites, 46% of respondents claim to have accessibility knowledge.
While 46% isn’t a terrible figure (it’s almost half), I doubt it is representative of all web designers and developers. The percentage could be much lower in reality. Further, just because a person believes he has accessibility knowledge, doesn’t automatically translate to implementation.
So, let’s try and change this.
At its foundation, web accessibility is simple. The W3C states:
“The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.”
Taken more specifically, web accessibility means:
Meeting these goals, however, has proved problematic due to poorly designed and developed web sites that create barriers for people with disabilities. Just a few of these barriers include:
And these are primarily focused on web content. The challenge gets even harder when interactivity for web applications is needed.
When most people hear the word “accessibility,” the next word they think of is “disability.” So let’s consider that for a moment. Disability refers to a broad range of impairments. When it comes to web accessibility, you have to consider all of the different types of people who need to be considered:
Yet this is still only part of the demographic picture. Web accessibility isn’t restricted to helping those with disabilities, it also helps:
And that doesn’t even complete the picture. Web accessibility is tied to today’s best practices, aiding in:
Web accessibility is really about ensuring your web sites and applications are accessible for all users and devices.
Despite the numbers I mentioned at the start of this article, I agree with Mark Twain when it comes to statistics. So, let’s consider a real-world scenario. A few years ago, the National Federation of the Blind sued Target for having a web site inaccessible to people using assistive technologies. The suit was settled, and Target was ordered to pay $6 million in damages to claimants.
Some argued the settlement doesn’t do enough for web accessibility, but it is hard to rationalize a $6 million price tag for something that could’ve been achieved by developing with simple, standards-based accessibility techniques.
And let’s not forget the market. According to the Americans With Disabilities, there are 51 million disabled consumers with $175 million to spend. And that’s just the US! It makes no business sense to alienate a market with that buying power, not to mention the potential legal ramifications of an inaccessible web site.
So, if all the reasons I’ve outlined above can’t convince you or your organization to invest in accessibility, then consider your bottom line.
Whether you develop sites or applications, you are, ultimately, dealing with content: text, images, forms, sounds, and the like. If accessibility is new to you, focusing on your content is a good place to start.
The Web Accessibility Initiative(WAI) has established the Web Content Accessibility Guidelines (WCAG) to serve as the standard for web content accessibility. It is organized around four design principles, which each address the common barriers to web content accessibility.
If you are a standards-based developer, you may already be following some of the guidelines, such as those for images:
What those two guidelines essentially mean is that if you have an image that contains text, you should assign the altattribute a value equal to the text in the image:
<img src="registernow.png" alt="Register Now!" />
And if you have an image that is purely decorative, in that it doesn’t contain any text, give it a blank alt value:
<img src="businessman.jpg" alt="" />
Similarly, you may already be following the guidelines for understandable content, including specifying the language of a page:
Or using semantic, rather than presentational, markup:
Or providing expansions for abbreviations:
<abbr title="Hypertext Markup Language">HTML</abbr>
For the purposes of this article, I'm not going to delve any deeper into WCAG 2.0. I simply encourage you to take the time to understand WCAG enough to ensure your content is accessible and take your development to the next level.
If you are into tech-speak, check out the WCAG 2.0 specification. For me, as with all W3C specs, the language is overwhelming. I much prefer, instead, to reference WebAIM's checklist, which provides a more simplified and understandable explanation.
While this new direction on the web offers most users a richer experience, these web applications present new accessibility barriers, the most common of which are:
Consider a web application that uses Ajax to update content. Most assistive technologies, like screen readers, don't inform users that the content has changed.
Similarly, applications using advanced user interface controls, such as a drag-and-drop, are missing essential information to allow for keyboard navigation. So, users who can't use a mouse, lack the ability to manipulate those controls.
To the rescue comes WAI's Accessible Rich Internet Applications (ARIA), which establishes guidelines for making today's dynamic content and advanced controls more accessible. I, personally, like the analogy that WAI-ARIA is like a microformat for accessibility. ARIA guidelines simply define markup attributes that provide assistive technologies semantic information needed to make applications accessible.
With today's current markup, there isn't a way to semantically indicate a document's structure, such as the navigation or main content. This makes it difficult for users of screen readers, for example, to navigate directly to specific portions of a page. In fact, this lack of structure is what heralded the introduction of “skip links.”
ARIA addresses this problem with the introduction of Document Landmark Roles, which are really just specific values assigned to the role attribute of relevant elements to indicate structure and aid in navigation:
The addition of these attribute-value pairs provides user agents, like assistive technologies, the semantic information needed to interpret the document structure and allow users to navigate accordingly.
Further, these roles aren’t limited to web applications. Many web sites today can add these attributes to aid accessibility, regardless of any application interactivity. For example, a site that uses an unordered list of links for navigation could increase accessibility by adding role="navigation":
Now, if you’ve been experimenting with or reading about HTML5, you may be starting to notice some of the crossover with WAI-ARIA document roles and the new sectioning elements in HTML5. And you’d be right … sort of.
HTML5 does, indeed, come with the lovely semantic elements <header>, <nav>, <article> and <aside>, which may seem to directly relate to some of the Document Layout Roles I’ve listed. But, for the most part, the relation is purely perceptual. In fact, for most of the roles, there isn’t a direct HTML5 equivalent.
The reference I’ve found most useful so far, is The Paciello Group’s Comparison of ARIA landmark roles and HTML5 structural elements. Basically, it states that the only direct equivalencies are:
In these cases, if assistive technologies support HTML5, then the corresponding ARIA document role can be dropped.
As always seems the case with emerging technologies, debates abound. Some people feel strongly that WAI-ARIA document roles directly contradict HTML5 structural elements and could cause subsequent conflicts in user agents. Others, like The Paciello Group, see distinctions.
Then there’s the debate against document landmarks because they don’t validate for HTML 4 or XHTML using the W3C Validator. Nor do they validate in HTML5.
So, what should you do? Decide what your priorities are. Are you even using HTML5? Does validation trump accessibility for you?
Along with aiding navigation by defining the document structure, WAI-ARIA also helps address keyboard navigation issues by extending the tabindexattribute.
In HTML 4, tabindex can be applied to the <a>, <area>, <button>, <input>, <object>, <select>, and <textarea> elements, with a value between 0 and 32767. This aids keyboard navigation by starting at elements with the lowest number and proceeding to those with the highest.
WAI-ARIA takes this notion further by allowing tabindex to be assigned to any visible element, which helps give custom widgets the ability to have navigational and programmatic focus.
Additionally with WAI-ARIA, tabindex can have a negative value, such as -1. This allows elements to have programmatic focus—via element.focus()—but not be included in the natural navigation order.
Let’s consider this in a simple tree menu, where I want the menu itself to be tab-navigable within the flow of document elements so I assign a tabindex value of zero:
For the nested menu items, though, I don’t want them tab-navigable. Instead, I want them navigable via arrow keys, so I assign a negative tabindex value:
<li tabindex="-1">Item 1
<li tabindex="-1">Item 1.1</li>
<li tabindex="-1">Item 1.2</li>
We’ve already seen the use of the role attribute for indicating the document structure and, subsequently, aiding navigation. WAI-ARIA also uses rolesto describe what the elements in a widget do; what type of control it is, such as menu, toolbar, slider, tooltip or tree.
Assistive technologies already understand the roles of HTML elements. For example, a <dl> is understood by a screen reader as a definition list of X items, where the <dt> value equals the <dd> value. But since widgets can use any element, assistive technologies need additional information to understand what those elements do.
In the case of the tree menu example, I can apply a role to the main element, as well as to the nested elements:
<ul tabindex="0" role="tree">
<li tabindex="-1">Item 1
<li tabindex="-1" role="treeitem">Item 1.1</li>
<li tabindex="-1" role="treeitem">Item 1.2</li>
Some of the most common WAI-ARIA widget roles are:
Reference the full ARIA list for more.
In addition to defining what widget elements do, WAI-ARIA provides the foundation for explaining relationships and states of widgets so that users of assistive technologies can better interact with those widgets.
Let’s consider a simple form that requires users to enter an email address. Without ARIA, assistive technologies have no information that a particular field is required. But if we add the aria-required widget attribute, users are notified that the field is required:
<input type="text" name="email" aria-required="true" />
ARIA states and properties include attributes assigned to user interface controls, such as the widget attribute aria-required, as well as:
With the abundance of Ajax applications today, I suspect dynamic content changes and updates have become a bane for users of assistive technology. For example, a widget that uses Ajax to update content may not notify a screen reader that an update has occurred.
Fortunately, the states and properties for live regions address this problem. For example, by assigning the aria-live property to an element, assistive technologies can expect updates from this live region.
Using the polite value, assistive technologies know to inform the user of an update once the user has completed activity:
The assertive value tells assistive technologies to notify users of an update immediately, although it should be used thoughtfully as it will interrupt users’ current tasks:
And if you don’t assign aria-live or give it a value of off, the user is not notified at all:
There are other live region attributes that can greatly increase the accessibility of dynamic content changes:
Reference the spec to gain a full understanding of these properties and their valid values.
WAI-ARIA is currently a draft, so you may be questioning whether you should use it. There truly are no hard-and-fast answers to this question, but there are also no negative effects from implementing WAI-ARIA other than validation issues.
From my personal perspective, I see no reason not to use it where it makes sense to you, your content and your application. Some even suggest treating WAI-ARIA as “progressive enhancement” for accessibility.
It is already supported by:
And, like many in the industry, I believe in paving the cow paths. I also embrace learning and implementing new technologies as they emerge, not only to identify potential improvements for my sites but also to keep my skills current.
As much as we’ve covered in this article, it is really just the surface of web accessibility and WAI-ARIA. There is so much more to know. Hopefully, I’ve piqued your interest enough you’ll also check out:
To help you on your journey into accessibility, also check out:
Emily Lewis is a freelance web designer of the standardista variety, which means she gets geeky about things like semantic markup andCSS, usability and accessibility. As part of her ongoing quest to spread the good word about standards, she writes about web design on her blog, A Blog Not Limited, and is the author of Microformats Made Simple and a contributing author for the HTML5 Cookbook. She’s also a guest writer for Web Standards Sherpa, .net magazine and MIX Online.
In addition to loving all things web, Emily is passionate about community building and knowledge sharing. She co-founded and co-manages Webuquerque, the New Mexico Adobe User Group for Web Professionals, and is a co-host of the The ExpressionEngine Podcast. Emily also speaks at conferences and events all over the country, including SXSW, MIX, In Control, Voices That Matter, New Mexico Technology Council, InterLab and the University of New Mexico.
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.