There is a lot of good advice for the discerning web developer to find on the web on how to make a website accessible, unfortunately there is also plenty of bad or outdated advice out there as well. Here are a few of the myths of accessibility that you may hear.
Validation equals accessibility
Good markup is the foundation of a usable, accessible and robust website. Testing that the HTML (and CSS) that you write passes a validation test can be very useful, and in general validity is something to strive for. As my colleague (and true accessibility genius) Benjamin Hawkes-Lewis puts it, valid code is a contract between you and the browser vendors – you write valid code, they will render it correctly (in theory!).
But this is not the same as accessibility, validators do not check that
alt attributes are relevant, or that link text is useful. They do not test page interactions to ensure that they are usable by all. They do not ensure that text is readable. All of these issues are more important than validation, and given a choice between accessibility and validation, accessibility should win every time. Sometimes it is necessary to ignore the specification altogether, and write invalid code. Learning when and why is something that requires experience and knowledge, along with much testing when the time come, but don’t let the idea that invalid markup is always bad put you off.
If it works with a screen reader it is accessible
I think the majority of developers and their clients have got passed the idea that visual impaired people do not use the web, however there is so much focus on screen reader users that it is easy to forget that there are other groups of users that we need to make the web accessible for.
Fortunately over the last year I have seen much more information and new tools made available for opening up the web for many more people, from YouTube’s automated captioning of videos to the interest shown at events like Standards.next with a focus on cognitive disabilities. I hope this continues.
Sites are either accessible or inaccessible
Accessibility is very subjective, even by comparing against guidelines such as WCAG 2.0 it isn’t really possible to grade how accessible a website is. Content that is highly accessible to a visually impaired user with a screen reader may be inadequate for a user who lacks fine motor control.
The point is that there is almost always room for improvement, and that it is worthwhile making small changes that improve the user experience for only a small number of people – every little bit helps.
Content that isn’t 100% accessible shouldn’t be published
There is a growing trend of criticising any content that isn’t accessible to everyone, and this is counter-productive. The web has thrived and become what it is today because it is easy to publish to, by almost everyone. We might hope for more accessible content on the web but we must not discourage publishers, for example while there is no doubt that captioning of YouTube videos is a great boon to many people I would not like to see the pressure to caption put anyone off uploading a new video. Authoring tools and automation are the key for helping small publishers and non-developers make their content accessible, and we shouldn’t criticise the author if the available tools are inadequate.
The pressure seems particularly great on developers, who apparently should be held to higher standards. Christian Heilmann mentioned this in conversation recently, talking about how developers avoid putting slide decks of presentations they have online because they are not in an accessible format. This is a situation that benefits no one.
I believe that open content that is inaccessible to 50% of people is better than content that is never published. Ideally it is published with a license that allows others to take it and convert it to different forms which may be accessible, but this isn’t possible if it only exists in a file on someone’s desktop.
I guess the theme of this post is that accessibility isn’t a target to aim for, it is a goal to aspire to. There is always something that can be more accessible, always another scenario that you have yet to consider, so release that application, publish that article, do your best the first time around and learn from mistakes when things don’t go well.