Developing an Accessible Web


Published on

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.

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Developing an Accessible Web

  1. 1. Developing anAccessibile Web Matt Henry Viget Labs
  2. 2. About Me• Senior Front-End Developer at Viget Labs• Ex-Yahoo! Mobile• @greenideas• Fan of owls
  3. 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. 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. 5. Progressive Enhancement1. Semantic HTML2. Web 1.0 interactions--reload required3. CSS4. Javascript
  6. 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. 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.
  8. 8. Demo
  9. 9. Building for Screen Readers• Alt attributes• Generated content• Clean, semantic HTML• Links are for navigating. Buttons are for doing stuff.
  10. 10. Bad<a href=”#”>Load my Ajax</a>
  11. 11. Better<a href=”#” role=”button”>Loadmy Ajax</a>
  12. 12. Best<button>Load my Ajax</button>
  13. 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. 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. 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
  16. 16. Demo
  17. 17. WAI-ARIA• Web Accessibility Initiative -- Accessible Rich Internet Applications• Label content for screen readers• Moar semantic
  18. 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. 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
  20. 20. Demo
  21. 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. 22. What are you still onthe 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. 23. Why ARIA?• Provide a non-visual representation of complication interactions in your application• Still more semantic• Easier styling & scripting
  24. 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. 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. 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.
  27. 27. Thanks. <3
  28. 28. Links• ARIA specification: wai-aria/• ARIA Authoring Practices: http://•• Derek Featherstone on ARIA in A List Apart: aria-and-progressive-enhancement/