Skip to content

Instantly share code, notes, and snippets.

@nimbupani
Forked from paulirish/gist:2731401
Created May 22, 2012 17:09
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nimbupani/2770321 to your computer and use it in GitHub Desktop.
Save nimbupani/2770321 to your computer and use it in GitHub Desktop.
draft post on a11y

Jacob Thornton has an inspiring slide deck on accessibility that brings to fore all the concerns that web developers have with implementing features around accessibility.

For a very long time, developers have been told about making websites 'accessible'. Like it is a faucet that should be turned on or off. Till [Victor Tsaran's demonstration of using a screenreader][] (which was in 2007 - a very long time since accessibility evangelism began) - very few web developers had any idea of the real immediate impact of implementing accessibility features.

It is also interesting that very few developers even knew that blind users of screen readers read at such an extraordinary speed that very few sighted users are capable of. What are some of the other abilities that disabled users of the web use to their advantage?

People like Jason Kiss and Steve Faulkner who detail the behavior and support in browsers and screenreaders are providing the developer community with invaluable knowledge, stuff that is far more worthwhile than publishing a yet another list of you-should-do-these-things. (See also my list at the end of the recent semantics post).

Most developers have no idea what effect adding ARIA markup to our documents has on people using screenreaders. We need that. Actual before-and-after video stuff makes this topic real. See [zomigi’s recent post: videos of screenreaders using ARIA][], for great examples.

Most developers have no idea how to implement ARIA. The [W3C Primer that looks like a spec][] is not at all appropriate for a web developer audience.

Just like it’s valuable to witness an a11y usability session where you see how disabled people use your site. I don’t think we need more on the ground evangelism yet. There is a dearth in online resources at the moment, developers need to know these practical ways of using and having users benefit from accessibility techniques:

  • What are the brain-dead steps to implementing accessibility features effectively on every site I develop?
  • Which features should I use and which should I avoid (which features are actively harmful because of shoddy screen reader/other a11y tech support?)
  • Videos of screenreaders in use (Thanks Zoe!)
  • What are the top priorities for developers to implement?
  • What one thing can I do as a web developer to my sites and apps that dramatically improves the UX for disabled users
  • How do some of these features work? What are they for? A demonstration of how each feature makes an impact or gets used by a user would be most helpful (e.g. focus rings wtf are they?).

It feels like yelling at a fucking brick wall with JAWS and Window Eyes. We just kinda hope and pray their support for things improve. As a pragmatic approach, I tell developers that if it works in NVDA, good enough. We have a mess of browsers we need to support already, dealing with ATs that lag years behind is not at all feasible.

A lot of developers do not understand that accessibility first comes from implementing the platform accessibility API by browsers such that screen readers can take advantage of the rendering. Most Operating Systems expose an API that allows browsers to map what is rendered on the screen to one of the interfaces that the Operating System's Accessibility API exposes.

Unfortunately, there has been no specification, so each browser has been left to do whatever it wants in terms of defining the relationship between a HTML element and the accessibility interface. Hopefully this will change with the HTML to Platform Accessibility API implementation guide and ensure each browser exposes each element consistently to the Platform Accessibility API.

Which shores up a greater concern: Better accessibility starts with the browser (and the platform). Browsers should be able to handle content loaded dynamically rather than expecting developers to do it for them. If content on a page that is displayed is altered, it needs to be noted to the accessibility api transparently instead of having developers bolt on extra markup to do so.

Accessibility should not be opt-in but opt-out.

(A while ago I read Karl Grove’s Barriers to improving the accessibility game plan. Probably the best post on a11y I’ve ever read. I really liked his approach in evolving the a11y strategy and left my thoughts. This is a longer version of that)

@paulirish
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment