Nick FreearAccessibility, internationalization, web dev, Moodle and other stuff

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:

1. 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,
2. Don't take HTML(5) markup for granted - whether you're generating it via Javascript in a big Web application, or directly on a small Web site. Use of headings <h1>, form labels <label>, <button> … is important,
3. Do markup things like buttons, well.. as buttons! Either directly <button title="Play video"></button> (ideal) OR <img role=button tabindex=0 title="Play video" /> (a WAI-ARIA hack),
4. 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,
5. 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,
6. 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,
7. 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 title attribute to the previous <button> example; an example of operable would be adding role and tabindex to the WAI-ARIA hack above… -- be aware that while standards and technologies change, general principles don't,
8. Do talk about what you're doing - not to show off, but to raise awareness; do contribute to the community - fixing problems, testing, encouraging…,
9. Do read, attend courses -- EHRC course, H807 on OpenLearn, H810 at The OU, Web Platform Docs, Dive into Accessibility, search …,
10. 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

Plenty of other people have their own takes on this.

What is your top tip?