This week I’ll be presenting two topics at Spring <br />, Web Accessibililty Acronyms and RIA Accessibility. As I was pulling together some resources to share, I pulled out a blog post I wrote for our Resource Interactive Technology blog. I figured I may as well share it here as well…
Is your site accessible? Web accessibility is making the news, with the target.com lawsuit[1] the most notable. It’s no longer enough for a developer to know Java, .NET, PHP, AS, HTML, CSS, JS, XML (insert other TLAs as applicable), now they’re expected to be experts on WCAG, W3C, ADA, WAI, WAI-ARIA, JAWS and Section 508, as well?
Is what we’re doing accessible? How do we know?
Testing for web accessibility is challenging; there are consultants[2, 3] who make their living on it, and many comprehensive (expensive) commercial tools[4]. However, there are several simple tools a developer can use to ensure he’s being conscious of some of the common barriers to accessibility.
Note: there is a difference between making a site comply with accessibility guidelines, and making one that is usable by people with different disabilities. The former may be assessed to some extent by automated tools, but user testing is really required to ensure a site is usable and provides visitors with a positive experience.
Automated testing isn’t infallible, and not all the guidelines are verifiable by automatic means. It’s been estimated that only about 25% of accessibility errors can be verified automatically. As well, the tools themselves aren’t perfect. Jim Thatcher[5] and Gez Lemon[6] have posted reviews of automated testing tools on their respective websites. Passing an automated validator does not guarantee a site will be accessible! However, it is more likely to be accessible than one that does not validate.
FireFox: a developer’s best friend
There are many FireFox extensions related to accessibility. A few of my favorites:
FireFox Accessibility Extension: Similar to the standard web developer toolbar, this offers many features related to accessibility. The “report” option applies to a single webpage, and records the frequency, severity and rationale for each reported issue. https://addons.mozilla.org/en-US/firefox/addon/5809
FANGS: A screen reader emulator. For anyone who’s tried to use a screen reader, it can be very hard to understand (and navigate!) FANGS offers a textual representation of how a page would be read on page load. This helps to see if content is accessible, but doesn’t help in terms of interaction. http://www.standards-schmandards.com/projects/fangs/
Fire Vox: For those not content with a screen reader emulator like FANGS, Charles Chen has created a fully-featured screen reader for FireFox. It reads changes made to the DOM, and does not have access to changes that occur within plugins (like Flash). Fire Vox does have support for live regions marked up for WAI-ARIA (proposed markup to help make AJAX accessible) http://firevox.clcworld.net/
Color Contrast Analyzer: This tool is moreso for designers than developers: it can be used to determine if the foreground and background colors of elements have “sufficient contrast.” This functionality is also available via the FireFox Accessibility Extension listed above, I haven’t compared the output from each. http://juicystudio.com/article/new-improved-colour-contrast-firefox-extension.php
Other techniques
Accessibility doesn’t just refer to blind users with screen readers. Color-blind, short-sighted and mobility-impaired users need to access your site as well. The following techniques can help you understand their experience.
Throw your mouse out the window: Tab through your site. Is it a painful process to actually get to the content on your page? Can you access all the actionable items?
Using skip navigation and semantic HTML markup can help *
Resize your font: Most browsers allow users to resize their font using keystrokes. What happens to your site when you increase your font size once or twice? Is it still legible?
Disable JavaScript: Can you perform all essential site actions without it?
That OTHER browser
Although I mention several FireFox extensions, it’s commonly believed that most users of screen readers are using Internet Explorer on Windows. There are some differences in how the different browsers interact with assistive technology, so it is imperative to perform testing in both environments. Vision Australia has an accessibility toolbar available for Internet Explorer: http://www.visionaustralia.org.au/ais/toolbar/
No one sets out to build an inaccessible site, but sometimes the end result is such. We may not be able to offer a visitor using assistive technologies (screen readers, screen magnifiers, pointing devices) the same rich, engaging experience as other visitors, but we should work to provide him with something. These tools help ensure at least some of the common barriers to accessibility are removed.
* Most screen readers allow users to bring up a “links list” or “headers list” so the visitor can navigate quickly to the section they’re interested in. HTML button or submit elements allow for a keyboard user to submit a form more easily than images that evoke JavaScript for form submission.
Citations
[1] http://www.eweek.com/c/a/Retail/Court-Rules-Against-Target-in-Web-Site-Accessibility-Lawsuits/
[2] http://www.wats.ca/showcategory.php?categoryid=14
[3] http://jimthatcher.com/
[4] http://jimthatcher.com/testing2.htm
[5] http://jimthatcher.com/testing1.htm
[6] http://juicystudio.com/article/invalid-content-accessibility-validators.php
No comments yet.