SlideShare a Scribd company logo

Developing an Accessible Web

•
•
G
greenideas

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.

Related slideshows

Sencha and Spring (Spring 2GX 2013)
Sencha and Spring (Spring 2GX 2013) Sencha and Spring (Spring 2GX 2013)
Sencha and Spring (Spring 2GX 2013)
 
Website
WebsiteWebsite
Website
 
はじめてのWKInterfaceController
はじめてのWKInterfaceControllerはじめてのWKInterfaceController
はじめてのWKInterfaceController
 
1 of 28
Download to read offline
Developing an Accessibile Web Matt Henry Viget Labs
About Me • Senior Front-End Developer at Viget Labs • Ex-Yahoo! Mobile • @greenideas • Fan of owls
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?
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
Progressive Enhancement 1. Semantic HTML 2. Web 1.0 interactions--reload required 3. CSS 4. Javascript
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.
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.
Demo
Building for Screen Readers • Alt attributes • Generated content • Clean, semantic HTML • Links are for navigating. Buttons are for doing stuff.
Bad <a href=”#”>Load my Ajax</a>
Better <a href=”#” role=”button”>Load my Ajax</a>
Best <button>Load my Ajax</button>
Input methods • Accessibility is more than just targeting screen readers. • Keyboards, sip & puff, head/eye trackers • Is your application usable without a mouse?
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
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
Demo
WAI-ARIA • Web Accessibility Initiative -- Accessible Rich Internet Applications • Label content for screen readers • Moar semantic
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,
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
Demo
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
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
Why ARIA? • Provide a non-visual representation of complication interactions in your application • Still more semantic • Easier styling & scripting
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.
Testing with Screen Readers • Make screen reader testing part of your cross-browser testing routine • OSX & iOS:VoiceOver is built in • Windows: NVDA
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.
Thanks. <3 http://spkr8.com/t/5431
Links • ARIA specification: http://www.w3.org/TR/ wai-aria/ • ARIA Authoring Practices: http:// www.w3.org/TR/wai-aria-practices/ • http://www.nvda-project.org/ • Derek Featherstone on ARIA in A List Apart: http://www.alistapart.com/articles/ aria-and-progressive-enhancement/

More Related Content

Developing an Accessible Web

  • 1. Developing an Accessibile Web Matt Henry Viget Labs
  • 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.
  • 9. Building for Screen Readers • Alt attributes • Generated content • Clean, semantic HTML • Links are for navigating. Buttons are for doing stuff.
  • 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
  • 16. Demo
  • 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
  • 20. Demo
  • 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.
  • 27. Thanks. <3 http://spkr8.com/t/5431
  • 28. Links • ARIA specification: http://www.w3.org/TR/ wai-aria/ • ARIA Authoring Practices: http:// www.w3.org/TR/wai-aria-practices/ • http://www.nvda-project.org/ • Derek Featherstone on ARIA in A List Apart: http://www.alistapart.com/articles/ aria-and-progressive-enhancement/