Make custom interactive elements focusable with
tabindex:
<!-- Natural tab order -->
<div onclick="" tabindex="0">Clicky 1</div>
<!-- Custom tab order -->
<div onclick="" tabindex="7">Clicky 2</div>
<!-- Focusable but not in tab order -->
<div onclick="" tabindex="-1">Clicky 3</div>
Proactively place focus with element.focus()
to create an efficient workflow.
Add key handlers.
Custom controls should respond to keys like Enter, Space,
Arrows, Escape, etc. as appropriate. Unplug your mouse and try it!
<div id="reply_icon"
tabindex="0"
onclick="reply()"
onkeydown="return onReplyKeydown(event)">Reply</div>
<script>
function onReplyKeydown(event) {
if (event.keyCode == 32 || event.keyCode == 13) // Space / Enter
reply();
}
</script>
Add ARIA for screen readers.
ARIA attributes provide semantic information to
screen readers that is normally conveyed visually.
Use the ARIA role attribute to indicate that
a generic tag is playing the role of a standard widget like
a button:
<div tabindex="0" role="button">Send</div>
Use ARIA states and properties to add dynamic information about the
current state of an element:
<div tabindex="0" role="checkbox" aria-checked="true">
Include attachments
</div>
Identify dynamic content as an ARIA Live Region.
Content that changes without a page refresh should be identified as a live region.
Add ARIA live region attributes to dynamic content:
Screen readers and magnifiers:
JAWS, ZoomText, NVDA, VoiceOver, ...
(Just like with HTML / CSS, there are platform differences and
some testing is required.)
Accessible HTML5 Recap
Use clean HTML, standard tags.
Manage focus.
Add key handlers.
Add ARIA for screen readers.
ARIA is easy if you already did the last three steps!
One last note: Screen readers and key handling
Some screen readers are modal - when the user is in
browse mode, all keystrokes get sent to the screen reader
instead of the page.
Only focused controls will reliably receive key events.
Do not rely on global key handlers!
An alternative for advanced developers is ARIA
role="application" - when the user is inside this
block, keystrokes all go to the page. Use with caution!
Part III: Extensions, Tools & Resources
Why is developing accessible web apps hard?
(Even for a developer who is aware of the need...)
There can be wide implementation differences between browsers,
platforms, and screen readers.
Older browsers and screen readers can't handle dynamic web apps.
No browser or screen reader has fully implemented ARIA yet.
There's no clear documentation on what is widely supported
in all tools.
The power of browser extensions
Web-platform browser extensions are quick to install,
secure, and powerful.
They're a perfect platform for:
Accessibility solutions for end users
Accessibility testing tools for developers
Google's extensions
ChromeVox
A screen reader for blind users.
ChromeVis
A magnifier for low-vision users.
ChromeShades
An accessibility testing tool for developers.
ChromeVox
Built-into Chrome OS, available as an extension for Chrome on
other platforms.
Pure JavaScript! Uses new experimental extension APIs in
Chrome for text-to-speech, and to listen to user interface events
in menus and toolbars.
Provides full access to dynamic web pages with ARIA, plus
includes support for custom site scripts for improved access.
ChromeVis
Magnifier for low-vision users.
Displays selected text in a high-contrast magnified lens for
easy reading.
Provides basic keyboard
commands to move the
selection around the page.
Preserves the original page layout.
ChromeShades
Accessibility testing tool for developers.
When ChromeShades is running, everything is reformatted
as text-only and organized more like how a blind
user would perceive the page with a screen reader.
Everything is still totally functional - you can still
click on links, buttons, and other controls.
Many accessibility problems become immediately apparent.