It’s only logical that people wonder what are the best in class accessibility examples of websites (and other digital products). We want to see what that means before we can start implementing it. Sometimes we need to see how it works with keyboard and screen-reader. Sometimes we wish to check the semantics. And sometimes we want to use the same component in our project.
Almost every time I do a presentation about accessibility or accessibility training somebody asks that question, so I decided to include some information in all my slides or at least explain the situation. And I hope that this blog post will help to explain as well.
Accessibility is often very subjective
Sure, we have the objective parts like standards and guidelines (they at least try their best to be objective). When we require accessibility in our legislation we need to have it as objective as possible. But in reality we need to be clear about the fact that accessibility is very subjective. Disabilities are a spectrum, people can also have multiple disabilities, we can come in situations where our needs are different, so it’s obvious that what is accessible in one situation isn’t necessarily accessible in another.
If we just think about screen reader users – some may not have any vision, some may have dyslexia and see the screen – some are expert users of their screen reader software and some are just starting with screen readers. Some use their desktop computers that enable them to have thousands of keyboard shortcuts and make them extremely effective with their screen readers while some may just use their mobile devices that have way more limited screen reader functionalities.
Therefore – it’s very difficult to say – our website is best in class when it comes to screen readers (and screen readers are just a small part of the overall accessibility).
Accessibility is subjective, and our guidelines (like Web Content Accessibility Guidelines) and standards (like EN 301 549) can’t incorporate this subjectivity perfectly. It’s quite difficult and often impossible to have objective and subjective guidelines at the same time.
That’s also why we can have products that conform to WCAG but are not really usable.
Digital products change all the time
Websites, apps and most other digital products change all the time – their content changes, their frameworks change, new features are added, old features are changed, I like to think that they are living organisms, even if they are only digital bytes in reality.
So – what can perhaps be accessible at this exact moment – can be totally inaccessible tomorrow. I have seen it. I have experienced it. I have been guilty of doing it and I have been happy to fix such scenarios.
That is also why a year old accessibility statement probably isn’t valuable anymore (Web Accessibility Directive demands that accessibility statements are updated at least once per year with a reason). When we consider what would be best practice with updates of accessibility statements, then I would suggest that they are following the releases of features and fixes – that would really mirror the reality. This is just a generalization though, as it’s easier to do with smaller projects and quite difficult with larger ones.
Even when we found good examples they may have issues in parts that we didn’t check
Especially with larger products or websites, with many features, pages, views – it can be difficult to say – this is best in class. Because we can’t really check everything and when somebody checks a part that we didn’t check they can find issues.
Scoping in auditing and testing is key. That’s also why we have WCAG-EM (WCAG evaluation methodology). Because often it’s not possible to check everything and we need to have smart scoping that helps us cover as much as possible.
But the same scope that was used for testing needs also to be clear in our accessibility statements or accessibility conformance reports, otherwise we risk over-promising.
I have not seen a lot of accessibility statements that include scopes and I wonder also why that is not a requirement. If we leave scope out, then we must assume that the whole webpage (or any other digital product) is the scope – and that is dangerous (especially with larger or more complex products).
I’ve collected hundreds of potential best cases and plan to do some research
There are some blog posts and articles listing “most accessible websites” and similar, and I’ve gone through dozens of them to collect the addresses. I’ve also got some feedback on Twitter (I decided that I will remain with Twitter), mostly from accessibility specialists and also noted the suggested addresses.
I’ve done quick manual and automatic tests on them, randomly selected addresses, and was able to find issues on all of them (no surprises there). Some issues are minimal and doesn’t present real world barriers and some were giant and total blockers. There were also some with issues in between. Therefore I needed to change the scoring from binary (conforming vs. non-conforming or failing) to a bit more realistic one. Spectrum based.
Perhaps I will share the results some day, but as I’ve written here – it’s extremely difficult as things change quickly. Perhaps my findings are not relevant for most of the sites the very next day.
There are still obvious differences in the levels of accessibility issues and it is quickly obvious which organizations or people dedicated accessibility considerations to their products and which did not.
I love the fact that WCAG version 3 will (most probably – remember – it’s still a draft) go away from this binary situation (or at least allow statistical weighting or representation).
Conclusion
Sorry if you expected me to promote some distinct websites or products. I can’t. It wouldn’t be quite fair.
Some are really good and really trying, but it seems that nobody is perfect. Or even if they are in this moment, I can’t vouch for them to be perfect when you will check a random page on their site (or a random view in their app).
Before people understand the guidelines, the subjectivity of accessibility or the continuous evolution and improvement on one side and continuous possibilities to introduce accessibility on the other side, it’s not smart to share examples that may cause people using problematic or non-optimal parts in their own products thinking that they did a good job and learning from the best.
We need to scope it down. Not to consider the whole page or app or product. We need to discuss distinct elements or parts. There are a lot of good examples there – on that level. Components, patterns, smaller parts really. But again in context. And that needs us to understand more before we can get inspired.
We need context. Context is key. We need to say it depends, even if it may sound like a cliche or that we are avoiding to provide proper answers – because it actually depends.