The WAI-ARIA specification has been a shot in the arm for accessibility on the web. In this talk, I'll cover the basics of building accessible web applications without ARIA, and then how to add ARIA for some extra accessibility magic.
2. About Me
• Senior Front-End Developer at Viget Labs
• Ex-Yahoo! Mobile
• @greenideas
• Fan of owls
3. This stuff is important
• More to accessibility than Section 508
• Try to use one of your apps with a screen
reader and without a mouse.
• Was it awesome? Could it be more
awesome?
4. Stop me if you’ve heard
this one before
• Okay, don’t actually stop me.
• Everything you know about accessibility
is... probably still right.
• Progressive enhancement and alt tags are as
important today as they ever were
5. Progressive
Enhancement
1. Semantic HTML
2. Web 1.0 interactions--reload required
3. CSS
4. Javascript
6. Accessibility vs.
Javascript?
• The good news: screen readers can
understand Javascript.
• The bad news: your sites still need to work
without Javascript.
• Site-critical interactions should work with
and without JS.
7. Hijax
• Jeremy Keith
• All of your links should be actual links (i.e.
there should be a real page that exists at
that href).
• Use JS to “hijack” the link, and do your
fancy Ajax magic.
13. Input methods
• Accessibility is more than just targeting
screen readers.
• Keyboards, sip & puff, head/eye trackers
• Is your application usable without a mouse?
14. Interacting via the
Keyboard
• Don’t (just) use :hover for interactions (this
helps make your app mobile-friendly, too)
• Anything you can do with a mouse, you
should be able to do with the keyboard
• Use tabindex to make elements accessible
via the keyboard
15. tabindex
• tabindex = 0: tab in document order
• tabindex = 1,2,3... : order by
tabindex value
• tabindex = -1: Element can’t be
tabbed to, but can be given focus
programmatically
• Explicit ordinal tabindex shouldn’t be
necessary
17. WAI-ARIA
• Web Accessibility Initiative -- Accessible
Rich Internet Applications
• Label content for screen readers
• Moar semantic
18. Roles
• Used to describe a document’s structure
• Landmark roles: application, main, section,
navigation, etc.
• Landmark roles overlap some with HTML5
elements, but you should still use the role
(e.g. <section role=”section”>)
• Widget roles: menu, toolbar, dialog,
19. States & Properties
• Used to describe an application’s state
• Global states: aria-busy, aria-
activedecendant
• Widget attributes: aria-pressed, aria-
hidden, aria-autocomplete
• Relationship attributes: aria-labelledby, aria-
controls
21. What does ARIA buy
you?
• Lots of semantic hooks to describe your
application’s functionality
• Guidance for how to construct a screen-
reader-friendly widget
22. What are you still on
the hook for with ARIA
• ARIA doesn’t give you off the shelf widgets
• You have to roll your own keyboard
support (unless you rely on what screen
readers give you)
• It’s your responsibility to manage focus
23. Why ARIA?
• Provide a non-visual representation of
complication interactions in your
application
• Still more semantic
• Easier styling & scripting
24. ARIA Support
• Good. Not great.
• Support depends on combo of browser +
screen reader
• Most modern browsers correctly expose at
least some ARIA roles.
• Like anything, check for support before
relying on ARIA for anything important.
25. Testing with Screen
Readers
• Make screen reader testing part of your
cross-browser testing routine
• OSX & iOS:VoiceOver is built in
• Windows: NVDA
26. Summary
• Yes, your app still has to work without
Javascript. Sorry.
• Hijax for content that you load in via Ajax
• Semantic markup
• Support the Keyboard
• Use ARIA. Be awesome.
