Your SlideShare is downloading. ×
Developing an Accessible Web
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Developing an Accessible Web

983
views

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 …

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
983
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 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 Enhancement1. Semantic HTML2. Web 1.0 interactions--reload required3. CSS4. 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.
  • 8. Demo
  • 9. Building for Screen Readers• Alt attributes• Generated content• Clean, semantic HTML• Links are for navigating. Buttons are for doing stuff.
  • 10. Bad<a href=”#”>Load my Ajax</a>
  • 11. Better<a href=”#” role=”button”>Loadmy Ajax</a>
  • 12. Best<button>Load my Ajax</button>
  • 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 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. 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. <3http://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/