I’ve been thinking about the goal of doing things accessible lately. It’s of course to make websites, web applications, native mobile applications and actually all digital products accessible to most people possibly, ideally for absolutely everybody.
But how do we know that a website is really accessible? Or an app/document/email/online video/podcast etc.?
Well we could argue that if we can audit the digital product based on Web Content Accessibility Guidelines (WCAG) Success Criteria (SC) on levels A and AA and everything passes we have make it really accessible, right? Well, this is not absolutely correct and unfortunately it is possible to pass all success criteria of the WCAG on all levels and still have some parts of the product inaccessible.
Although content may satisfy all Success Criteria, the content may not always be usable by people with a wide variety of disabilities.
WCAG – Understanding Conformance (opens in new window).
WCAG helps a lot but also has some parts that can be open to different interpretations
WCAG requirements (success criteria) are written as objectively as possible so that we can test them and expect to always get same results. But at the same time WCAG tries to be indifferent of the technology and there are therefore some parts that may give different results based on different expert’s opinions and practice. So sometimes we may get an audit results that passes all success criteria but same product may have some success criteria that fail with different auditors.
One simple example is alternative text on an image – it can really depend on the context, authors intentions and then also on auditors preferences – is it really the best choice for that picture? Or maybe missing audio descriptions that could not be a real problem when captions covered the missing parts already…
Some parts of WCAG can get very subjective…
WCAG is really working hard to make things as objective as possible though, but at the same time this may be a very difficult task especially when we have to take in regards multiple different disabilities and also combinations of them that may help some people but harm other and so on. So it really is a complex situations in some cases and that should be understood.
It’s sometimes impossible to test absolutely all parts of the product
If we think of large websites – it can really be impossible to test and verify absolutely all pages and page variants in most cases. Even WCAG Evaluation Methodology (WCAG-EM) is realistic about it and defines scoping of evaluation very general. So it is possible that some users visit sites that were not evaluated and may have big accessibility issues.
Some automatic testing can help with large sites but we must remember that automatic testing is very limited and that it only finds errors but can not provide us with certain passes.
Content changes can break previously accessible pages
That should not be difficult to understand. Content can change often sometimes and content creators bear a huge part of responsibilities for accessibility, especially after audits are done. That’s why it is extremely important to understand that audits are reflecting state of some parts of the product at the distinct point in time.
The older the audit the more chances that product is less accessible.
common sense – products evolve quickly, so audits can be outdated quickly as well.
Usability testing can sometimes discover that WCAG is not enough
Accessibility and usability are closely connected. But where there are quite clear rules for accessibility those are sometimes not so clear for usability. Add different combinations of assistive technologies, browsers and persons with disabilities to the situation and it may very quickly show that some parts may be totally unusable for some.
Browser support, assistive technology support, browser and assistive technology combinations, users disabilities or combinations of them, situational surroundings and so on can produce quite interesting discoveries.
Some parts can be taken into consideration from the start, like technical support and some can’t. For example we could test with different combinations of screen-readers and browsers and find out if there were some problems that are specific to them and then note it in our accessibility statement or Voluntary Product Accessibility Template (VPAT).
Complexity of assistive technology and supporting it
Some parts of WCAG are closely related to code. This same code has to be interpreted by user agents like browsers and also assistive technology. We must not think about assistive technology (AT) only as screen-readers. There are a lot of other technologies that can be used by people with different disabilities and they are constantly evolving and getting more advanced. Some are very basic and some are extremely complex. So we can never really guarantee that our product will support all kinds of different AT.
We must do our best that our code is robust, correct, semantic and tested as much as possible. But that is only the start. Some screen-readers are for example interpreting parts of code differently, some are not supporting all HTML tags for example. So it can get very frustrating – fixing things for one screen-reader can have negative consequences for others and so on.
Our best chance is to be as proactive as possibly – checking support for our cases, when experiencing bugs reporting them and following up on them and be connected with accessibility community and cooperate on best practices and ideally also open source solutions that can solve common problems.
Include people with disabilities early and often – then you may have a chance
As mentioned in the start – WCAG are only guidelines and do help but only up to a point. We should not be overconfident in our design, coding and content deliveries when it comes to accessibility. Let me provide some simple situations that can make us feel good but can make our product less or even not accessible at all;
- It’s too easy to just add some additional ARIA attributes on some parts in the code and make assumptions that it will give the best user experience for everybody.
- It’s too easy to read an article on some dyslexia friendly font and then use it and feel good about ourselves that we made our product more accessible with that.
- It’s too easy to write an alternative text to an image that is too short to really reflect the meaning of that important infographics.
- It’s too easy to only have automated captions for our webinar and not even check them for errors, neither add who was really speaking.
I can unfortunately make an extremely long list of similar situations and I hope you get the point. Involving people with disabilities early and often is the best possible way to make things accessible. WCAG is the minimum that we should get to know but then there is also the human perspective and cooperation with people with disabilities is actually the best practice. We must do all we can to make products accessible but we must also involve them in all parts of the processes, from ideation, concepts, to design, development, content development and also testing. That is the only way.
Stating that our product are accessible without testing them with real users can quickly be untrue. We may claim that we are doing our best in regards of WCAG and maybe we can even claim WCAG conformance for parts of our product that were actually tested but only real users can tell if our product is accessible to them.
