My accessibility top 10 do’s and don’ts
2012-10-25 07:34:00 -0700
Quoting from a recent blog post by Marco Zehe,
There are those days when you watch a discussion unfold on Twitter, and a point is reached where a statement is made that leaves you more or less speechless for a while.
Like Marco, I'm a little dismayed by what the discussions on Twitter and his blog seem to reveal.
And, to quote from Molily’s comment,
The majority does not consider accessibility as a crucial part of HTML5 (as an umbrella term). People are building huge apps and interactive experiences with HTML5. Accessibility isn’t necessarily a built-in feature. When people talk about HTML5, accessibility isn’t naturally included.
Quoting from And’s comment,
So what are the top 5 or 10 pragmatic dos and don’ts?
I'm always one for a challenge, so here are my top 10 dos and don'ts:
- Do install/ experiment with some tools and techniques -- NVDA screen reader on Windows; VoiceOver on Mac OS X; Windows high contrast; navigating with the keyboard (TAB, shift+TAB); the HTML CodeSniffer -- but don't expect validator/lint tools to find all the problems,
Use of headings
<h1>, form labels
<button>… is important,
- Do markup things like buttons, well.. as buttons!
<button title="Play video"></button>(ideal) OR
<img role=button tabindex=0 title="Play video" />(a WAI-ARIA hack),
- Don't assume that just because you are using a framework/ library/ whatever, then you have accessibility covered. There are some examples of active accessibility/usability movements within development communities, eg. Drupal UI standards, Drupal group, but there are plenty that need help,
- However, do use abstractions, for example a form library; oEmbed or
<iframe>s for embedding… -- this way accessibility/ usability bugs can (hopefully) be fixed in many places simultaneously,
- Do think about the process - require accessibility and usability standards in specifications/ tenders, build in training, build in testing, build in bug fixing BS 8878,
- Do use standards -- they aren't always scary, and WCAG 2.0 has a "top four" --
perceivable, operable, understandable, robust (POUR) --
An example of perceivable would be adding the
titleattribute to the previous
<button>example; an example of operable would be adding
tabindexto the WAI-ARIA hack above… -- be aware that while standards and technologies change, general principles don't,
- Do talk about what you're doing -- not to show off, but to raise awareness; do contribute to the community -- fixing problems, testing, encouraging…,
- Do read, attend courses -- EHRC course, H807 on OpenLearn, H810 at The OU, Web Platform Docs, Dive into Accessibility, search…,
- Do take small steps, make small improvements -- even if accessibility isn't built in from the start there is usually something that can improve the experience of end-users.
I'm aware that the above list mixes big picture and nitty-gritty points, and possible
What is your top tip?