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.
In conclusion…
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.
These are all very good points and I especially liked to read the one about HTML validation – it’s very easy to spot invalid code and it seems many people are very keen to do so and point it but, as you say, sometimes compromises have to be made and may not seem obvious at first glance.
Great article, I especially like your comments on screen readers. I often find that people, especially around the U.S. federal government go much further and require that something works with JAWS, or even say “JAWS accessible”. Now, I understand that this is the screen reader the federal government purchases for the most part, but unfortunately JAWS, without any further specifications, became a synonim for screen reader. This creates lot’s of issues when it comes to testing.
Great post — enjoyable read. I especially agree with the points like “Sites are either accessible or inaccessible”.
It doesn’t have to be all or nothing. Both with accessibility and web design in general, I’ve been seeing more and more the value of incremental improvement.
A site that isn’t perfectly accessible isn’t a “failure”, so long that there continues to be effort in making it usable by as many people as possible.
Ian, thanks for taking the sensible high ground in the ongoing discussion of accessibility. Not only is the degree of accessibility of a website, document, or other content a judgment call, but it’s impossible to foresee and prepare for all possible combinations of disability. I advise my co-workers to make their documents as accessible as they can, but remain committed to improving the accessibility of any document when and if an issue is brought to their attention.
As an overly simple example, I might make my site accessible to people who are deaf and people who are blind, but fail to realize that one feature isn’t accessible to anyone who is both deaf and blind. I don’t believe that would mean I had done anything wrong; instead, it would simply mean that anyone who is hindered by that barrier should bring it to my attention and, when they do, I should find a way to make that content accessible to them.
I’m glad you mentioned the importance of considering accessibility and cognitive disabilities. I imagine that slide presentations are the most frequent offender on this count. The endless lists of bullet points, poorly designed charts, and enigmatic figures that make up the typical slide presentation today are inaccessible to almost anyone who did not see and hear the actual presentation. But if the presentation is crafted so people with cognitive disabilities can learn everything from the slides themselves, then anyone who missed the presentation can, too. And if the presentation meets this standard, it should be trivial to make it accessible to people who rely on a screen reader to get to the content.
After all, although our goal in making content accessible is to give people who have disabilities an experience equivalent to that of people who don’t, there isn’t much use in ensuring that the shared experience is a befuddled feeling.
Or, as I’ve often said, if it isn’t usable for everyone, it can’t be accessible to anyone.
In theory, I agree with the “validation” and “100%” points. But in practice, I fear that developers would use this as an excuse and continue to publish inaccessible, crap code. What’s the motivation for a naive developer if there’s no need to be fully valid nor accessible?
Web Axe, I hear what you are saying. I certainly don’t want this to be an excuse for bad code, but conversely valid is not always the same as good or accessible, although of course valid code should be the starting point.
In my experience developers who have any understanding beyond a check box approach to accessibility tend to be conscientious and dedicated. I feel that it is counter-productive to be overly critical of those who may make mistakes but are committed to learning from them. I’d rather encourage these developers to release code / slide decks / applications than make them fearful to expose their work to the gaze of the accessibility community.
Nice article. We need more like this because there are too many authors out there who believe accessibility is about screen-readers.
This is the reason why we are using techniques (i.e., negative text-indent) that *target* these UAs, but miss the big picture.
Also, because of ARIA and interesting HTML5 techniques/attributes regarding form controls, I don’t think we can expect our documents to validate…
Interesting post, and brings up some valuable points.
I guess one can argue that not all sites need to be accessible, but certain ones (e.g. government sites) most certainly do.
Perhaps I’m missing out on something, but how can one test their website to see just how accessible it is? Is obtaining the target device and simply testing it the only answer?
It concerns me that validation of code is so highly in focus. Yes it should be part of making your content machine readable but it is not the be all and end all of accessible content.
The interaction between human and content is more important than valid code and I think it is these practises that need engrained into peoples psyche.
“I believe that open content that is inaccessible to 50% of people is better than content that is never published.”
wow – so you would say that hearing people can enjoy listening to uncaptioned videos and untranscribed podcasts??
deaf user, thanks for commenting.
A large proportion of web content is created by people who don’t have the knowledge or technology to make it accessible to all, even if such a thing is possible. Should they be prevented from sharing their videos and podcasts with the world? I hope you do not take this stance.
Should we hold web professionals to a higher standard? Perhaps, but with the best will in the world resources are still limited, knowledge is imperfect.
If a podcast is never published because the creator has not transcribed it how does a deaf user benefit? On the other hand if the same podcast is released under a license that allows another person to transcribe it then everyone benefits!
Bookmarked!
Wish some of my customers could understand this… validation does not equal accessibility.
Great post, Ian.
I agree with all your points, and they needed to be made.
I’ve gone further for Christmas 2011 and published my own accessibility myths blog, to take us on to where we need to be in 2012.
Check it out at: http://www.hassellinclusion.com/2011/12/accessibility-myths-2011/
I’d love to know what you think.