A great article by Eric Bailey crossed my twitter stream: “Accessibility auditing and ego“. It triggered a couple of thoughts I would like to “yes and…”.
I paused at this comment about WCAG:
it is a standard that sets normative, objective criteria for what is and what is not accessible
I mildly disagree with WCAG saying what is accessible. My logic goes like this:
- Digital Accessibility is: How easy it is for someone with a disability to use this digital product. (Like usability, an attribute of a product.)
- The things which impact accessibility can be from the full range of human-related issues. Going back to the Elements of user experience, it could be that the interface simply doesn’t fulfil the user-need, or feature set isn’t right.
- Areas which guidelines can cover tend to be at the interaction/information/visual design layers.
- There are areas of the experience which no guideline can cover, therefore guidelines alone cannot say what is accessible.
An example of the feature set not being right (for accessibility) is: If you provide a listing of TV programs, a small proportion of which are audio described, a make-or-break feature is to show which have audio description. Otherwise you have to use trail and error for finding videos you can watch. (Even better would be to have a dedicated listing.) No general set of guidelines can be that context-specific on a pass/fail basis.
Even within the top-layers of the experience, the guidelines are reasonably strong where you can say things like “If this thing is designed to look like a heading, make sure the mark-up is appropriate.”. However, they are not so strong where content might need to be re-configured to be accessible, such as where content does not use headings at all.
Does that mean the guidelines are useless? Of course not. If anything, you really need to consider the guidelines a baseline.
They are a list of known barriers, if your pages do not pass the guidelines there are known barriers in them that really have to be addressed. You can also read around the guidelines (e.g. the understanding documents) to work out what best-practice might be, however, I’d recommend the WAI tutorials for that purpose.
I think that is often why people try to reinterpret the guidelines to fail things they don’t like. You look at an interface in context and think that it is going to cause issues for people. That it is very possible, it might be a terrible interface. However, the guidelines have to be written to apply across contexts, so they tend to be quite conservative in what they catch. (This is the area of WCAG 3 I’m most excited about, better accounting for context.)
Eric is spot-on when talking about ‘staying in your lane’, and an audit should be clear about what fails and what does not.
Where I would “yes and…” is to say that it is also useful to report (separately) where you think the UX might be failing users. Those issues could provide useful clues about what else end-users might complain about, which could help the legal process.
In a scenario where the organisation is being sued the non-fails won’t be their top priority. However, next time they start non-panicked re-design work you might have planted seeds like:
- If you tackle accessible from the the start it doesn’t cost more;
- An early focus on accessibility tends to create a more robust, better quality product.
There are more seeds to drop, but I would use specific examples from the site to draw those out.