We have well known robots.txt, a bit less known humans.txt and seemingly very important security.txt. Is it also time for accessibility.txt? A uniform info about how accessible the site claims to be and how to contact people that can help us if we experience problems?
Writing a blog post on the 25th of December allows me to write about wishes. And one of them is to have better tools for accessibility auditing.
This post tries to describe what I would like to get from the tool. Realistically, noting too advanced.
We all reach out to third party solutions and we like it when they claim they are accessible. But please don’t just believe them – check that they really are conforming. And when they update – check again.
I was asked if I can issue “WCAG certificate” for a website, so I decided to investigate what would that actually mean as we all know that sites and mobile apps are constantly evolving and changing and even if they conform to WCAG they may not the following day. What would then mean to issue a WCAG certified certificate and still be ethical and the right thing to do?
What would I want from my Accessibility-as-a-Service provider? What would be the ideal here when we know that automatic testing is absolutely not enough? We must also get people as a part of the service – accessibility specialists and people with disabilities. And when done from start to end it is way more efficient compared to only using it at the end.
To claim that our product is accessible needs more than just WCAG audit that did not discover any fails. Real users, people with disabilities are the only one that can really reflect on the accessibility of our products. That’s why we should include them in all reasonable parts of our production processes. Otherwise we may think we deliver accessibility but the truth can be opposite.