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.
What Is Web Accessibility?
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:
- Ensuring that people with disabilities can perceive, understand, navigate, and interact with the web
- Ensuring people with disabilities can also contribute to the web
- Designing web sites and software that are flexible to meet different user needs, preferences, and situations
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:
- Missing alternative (
alt) text for text-based images - Missing keyboard functionality
- Missing text transcripts for audio
And these are primarily focused on web content. The challenge gets even harder when interactivity for web applications is needed.
Who Is Affected by Accessibility?
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:
- Those with any visual impairment. This could be a person who is completely blind or someone with low-vision. It can even be an older user who has trouble viewing a monitor.
- Those with any hearing impairment, including someone who is deaf, as well as someone who is hard-of-hearing.
- Those with mobility impairments that, in particular, restrict use of hands and arms. This could be someone with Multiple Sclerosis or even someone who recently had hand surgery and can’t use a mouse.
- Those with cognitive and learning impairments such as dyslexia.
Yet this is still only part of the demographic picture. Web accessibility isn’t restricted to helping those with disabilities, it also helps:
- People who aren’t fluent in the language on a site or who have low literacy
- People who don’t have broadband access
- People using older browsers
- New or infrequent users
And that doesn’t even complete the picture. Web accessibility is tied to today’s best practices, aiding in:
- Mobile web design
- Usability
- Device independence
- Search engine optimization (SEO)
Web accessibility is really about ensuring your web sites and applications are accessible for all users and devices.
The Bottom Line
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.
Accessible Content: WCAG 2.0
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.
- Perceivable: content is available to the senses (sight, hearing, and/or touch)
- Operable: interface forms, controls, and navigation are operable
- Understandable: content and interface are understandable
- Robust: content can be used reliably by a wide variety of user agents, including assistive technologies
If you are a standards-based developer, you may already be following some of the guidelines, such as those for images:
- All images, including those used for form buttons and image maps, must have equivalent alternative text.
- Decorative images must have null alternative text or be implemented via CSS backgrounds.
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:
<ul id="navigation">
<li><a href="/">Home</a></li>
<li><a href="/About/">About</a></li>
...
</ul>
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.
Accessible Applications: WAI-ARIA
WCAG, as I explained, focuses on content. And, for the most part, relies on how markup natively works in browsers and assistive technologies. With the advent of web applications, however, developers have taken HTML beyond what it was originally intended for, creating custom widgets and using JavaScript to manipulate behavior.
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:
- Lack of keyboard navigation
- Lack of information enabling assistive technologies to map dynamic widgets to a text interface
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.
Defining Structure: Document Landmark Roles
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:
role="banner" should be assigned to elements containing site-orientated content, such as the name of the site, title and/or logo.role="navigation" should be assigned to the element containing navigation links.role="main" should be assigned to the main content.role="search" should be assigned to the element containing the site search.role="article" is assigned to content that is stand-alone; it makes sense out of context from the rest of the document.role="complementary" is assigned to content that is supplemental to the main content.role="contentinfo" should be assigned to meta child content, such as footnotes and copyrights.role="application" is assigned to regions of the page containing application content and functionality. Note that this role is unique for two reasons: 1) if assigned to the entire page, it is not treated as a navigational landmark and 2) it tells screen readers to switch out of “browsing mode” into “application interface mode.”
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":
<ul role="navigation">
<li><a href="/">Home</a></li>
<li><a href="/About/">About</a></li>
...
</ul>
What About HTML5?
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:
<nav> androle="navigation"<aside> androle="complementary"<footer> androle="contentinfo"
In these cases, if assistive technologies support HTML5, then the corresponding ARIA document role can be dropped.
Be Aware
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?
Keyboard Navigation Via tabindex
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:
<ul tabindex="0">
<li>Item 1
<ul>
<li>Item 1.1</li>
<li>Item 1.2</li>
</ul>
</li>
...
</ul>
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:
<ul tabindex="0">
<li tabindex="-1">Item 1
<ul>
<li tabindex="-1">Item 1.1</li>
<li tabindex="-1">Item 1.2</li>
</ul>
</li>
...
</ul>
Defining Widget Roles
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
<ul>
<li tabindex="-1" role="treeitem">Item 1.1</li>
<li tabindex="-1" role="treeitem">Item 1.2</li>
</ul>
</li>
...
</ul>
Some of the most common WAI-ARIA widget roles are:
progressbarsliderbuttontreetextfieldcheckboxalertdialog
Reference the full ARIA list for more.
Defining States and Properties
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:
- Drag-and-drop attributes to indicate, you guessed it, draggable content and drop targets
- Relationship attributes to indicate associations between elements that can’t be determined via the document structure
- Live region attributes to indicate content changes and updates
A Closer Look at Live Regions
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:
<p aria-live="assertive">
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:
aria-atomic indicates whether all or part of the changed live region should be presented to the useraria-busy indicates that the live region is currently updatingaria-relevant indicates what changes to a live region are relevant
Reference the spec to gain a full understanding of these properties and their valid values.
Should You Use It?
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:
- Firefox 1.5+
- Opera 9.5+
- IE8+
- Webkit
- JAWS 7.1+
- Windows-Eyes 5.5+
- NVDA
- Zoomtext 9+
- FireVox
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.
Further Reading
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:
Tools
To help you on your journey into accessibility, also check out:
About the Author
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.
Find Emily on:
Comments (0)
