Accessibility is not just about addressing specific disabilities, but making sure as many people as possible have access to the same information. There’s rarely a good reason to lock people out when openness is a foundational principle of the web.

Written by Heydon Pickering and reviewed by Steve Faulkner.


Web accessibility is quite a large topic — far too large to fit into a small book. So, what will this book cover? Though we shall encounter visual design challenges, deal with performance issues, and adopt progressive enhancement — all of which are accessibility concerns — the underlying theme of this book is about making the interactivity of web applications include keyboard and screen reader users.

Starting with defining simple button controls and moving on to create reusable, accessible widgets, this book is about making interactions possible and meaningful for those who suffer from cognitive and motor impairments, as well as users who experience a range of vision impairments. However, the lessons learned from addressing the specific requirements of those using assistive technologies or consuming information in unusual ways can be applied to enrich the web for everyone. We all win.


  • Chapter 1: This Is For Everyone
  • Chapter 2: It’s All About Buttons
  • Chapter 3: The WAI Forward
  • Chapter 4: Getting Around
  • Chapter 5: Peekaboo
  • Chapter 6: It’s Alive!
  • Chapter 7: Welcome To The Community
  • Credits

Technical Information

  • Formats: PDF, EPUB, Kindle (DRM-free)
  • Pages: 121
  • Language: English
  • Released: June 2014
  • Publisher: Smashing Magazine GmbH
  • ISBN (PDF): 978-3-94454079-5
  • ISBN (EPUB): 978-3-94454080-1
  • ISBN (KINDLE): 978-3-94454081-8

Excerpt From Chapter 2

It’s All About Buttons

It’s easy to think of using proper semantic HTML as fussy and overparticular; that using the right element for the job is not really that important. Since you can attach JavaScript events to any old element and you can make any old element look like a button with CSS, isn’t which element you use a bit academic?

It can seem that way, but no. You see, web standards are all about agreement. It’s only through agreement that things can be made to work and behave in ways that are predictable for the greatest number of people. By designating certain behaviors to the <button> element, browser vendors can agree on how the element should be rendered and how it should behave. This way, authors like you and I will know which element to code if we want to elicit these behaviors. We work with the browser vendors to make our users’ lives easier. By convention, they know what they’re getting when they encounter a button.

Excerpt From Chapter 5


You won’t get far on the web these days without stumbling on some sort of tabbed interface. You know the kind of thing: a line of tabs, like those used in a filing cabinet, with each corresponding to their own pane or panel of content. It’s a popular pattern because it allows users to browse and switch between content, excluding from view anything they’re not interested in.

In fact, tabbed interfaces are so popular, it’s tempting to think of them as done: the JavaScript to show and hide panels is easy to write and easier to steal, which just leaves the visual design to be pondered. […]

Important questions I’m sure, but a good-looking tabbed interface does not a good tabbed interface make — not on its own. Is the underlying structure properly semantic and accessible? The JavaScript shows one panel and hides the others, but is this action really communicated to everyone? Can everyone perform that action in the first place?

Customer Reviews

Based on 4 reviews Write a review

Related Products

↑ Back to top