1.Developing anAccessibile 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 screenreader and without a mouse. Was it awesome? Could it be moreawesome? 4. Stop me if youve heardthis one before Okay, dont actually stop me. Everything you know about accessibilityis... probably still right. Progressive enhancement and alt tags are asimportant today as they ever were 5. Progressive Enhancement1. Semantic HTML2. Web 1.0 interactions--reload required3. CSS4. Javascript 6. Accessibility vs. Javascript? The good news: screen readers canunderstand Javascript. The bad news: your sites still need to workwithout Javascript. Site-critical interactions should work withand without JS. 7. Hijax Jeremy Keith All of your links should be actual links (i.e.there should be a real page that exists atthat href). Use JS to hijack the link, and do yourfancy Ajax magic. 8. Demo 9. Building for Screen Readers Alt attributes Generated content Clean, semantic HTML Links are for navigating. Buttons are fordoing stuff. 10. BadLoad my Ajax 11. BetterLoadmy Ajax 12. BestLoad my Ajax 13. Input methods Accessibility is more than just targetingscreen readers. Keyboards, sip & puff, head/eye trackers Is your application usable without a mouse? 14. Interacting via theKeyboard Dont (just) use :hover for interactions (thishelps make your app mobile-friendly, too) Anything you can do with a mouse, youshould be able to do with the keyboard Use tabindex to make elements accessiblevia the keyboard 15. tabindex tabindex= 0: tab in document order tabindex = 1,2,3... : order bytabindex value tabindex = -1: Element cant betabbed to, but can be given focusprogrammatically Explicit ordinal tabindex shouldnt benecessary 16. Demo 17. WAI-ARIA Web Accessibility Initiative -- AccessibleRich Internet Applications Label content for screen readers Moar semantic 18. Roles Used to describe a documents structure Landmark roles: application, main, section,navigation, etc. Landmark roles overlap some with HTML5elements, but you should still use the role(e.g. ) Widget roles: menu, toolbar, dialog, 19. States & Properties Used to describe an applications 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 buyyou? Lots of semantic hooks to describe yourapplications functionality Guidance for how to construct a screen-reader-friendly widget 22. What are you still onthe hook for with ARIA ARIA doesnt give you off the shelf widgets You have to roll your own keyboardsupport (unless you rely on what screenreaders give you) Its your responsibility to manage focus 23. Why ARIA? Provide a non-visual representation ofcomplication interactions in yourapplication 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 atleast some ARIA roles. Like anything, check for support beforerelying on ARIA for anything important. 25. Testing with Screen Readers Make screen reader testing part of yourcross-browser testing routine OSX & iOS:VoiceOver is built in Windows: NVDA 26. Summary Yes, your app still has to work withoutJavascript. Sorry. Hijax for content that you load in via Ajax Semantic markup Support the Keyboard Use ARIA. Be awesome. 27. Thanks.