I’m at a sxsw panel on accessible javascript. Here are the presenters:
|
Patrick Fox |
|
Becky Gibson |
Accessibility is all around us in the real world – curb cuts, access ramps, closed captioning. Accessibility is and should be ubiquitous. Accessibility benefits all of us – we watch closed captions when we’re watching a basketball game in a bar, we use curb cuts for strollers and bikes.
Semantic HTML is the foundation of accessibility. Your markup should indicate where headings, menus, links, etc. are. The essential part of making javascript accessible is to start with a normal page with good markup, and add the javascript afterward in such a way that the page looks normal with javascript turned off.
The sxsw website, for example, is completely reliant on javascript for its functionality. It’s unusable with javascript turned off. Also, rather than identifying the links as links, they are divs with a javascript “onclick” command. They should at the very least have anchor links.
You can use style sheets to show content if the user has javascript disabled, and hide it if the user has javascript enabled.
You should provide both mouse and keyboard events so that users can navigate with keyboard only.
Don’t mess with the functionality of the browser – don’t change how the up and down keys work, how the tab key works, etc.
There is a program called WAI-ARIA that is working on making web 2.0 accessible. It transmits data to assistive technologies (ATs) like screen readers informing the AT what sort of element it is looking at. So if you have a menu with collapsible sections, the AT would recognize that and alert the user.
ARIA also makes items “focusable,” meaning the AT can look at specific elements using tabindex.
ARIA can alert the user if ajax has updated any part of the page. Users can turn off the updates, make them “polite” – meaning that it waits until the AT is done reading or completing it’s current task, or make them “assertive” – meaning that it interrupts whatever is going on.
Examples of ajax updates would be autosaving a blog post and new email arrival. A screen reader user set on “polite” would hear that they have new mail after the screen reader finished reading out the email that it is currently reading.
ARIA works on JAWS 10 and Firefox 3.
To interface with ARIA, your page should have different regions which are identified by a “role” attribute, such as “main,” “banner,” or “navigation.” When the user looks at the page with a screen reader, the screen reader will tell the user what regions are on the page and allow the user to choose a region using the keyboard. The page can indicate to ARIA which regions are “live,” meaning that they might be updated by javascript or ajax. ARIA will watch those regions and alert the user if they change.
However, the page should still determine whether the user has javascript turned on, and serve them a static page if they do not.
Coding for ARIA does take more time, but JavaScript Toolkits have ARIA integrated so that it happens automatically.
Dojo is an open source javascript toolkit that fully supports ARIA.
