Accessibility statements are sometimes required and sometimes not. If your website or mobile application is a part of the public sector in the European Union it’s a requirement. If you are partially funded by public sector it may be a requirement. Depending on your local European Accessibility Act legislation implementation you may even be required to have an accessibility statement, even if you are private sector (e-commerce, banking, parts of transport services and communication services etc.).
Nevertheless – I strongly suggest you have an accessibility statement, even if you are not required to. Because when it’s not just a copied template and really provides transparent information about (in)accessibility of your website or mobile app – it makes it very clear that you cared enough to check what works and what not with accessibility in mind.
This makes things transparent to users with and without disabilities (and authorities). Some may stumble upon problems and need help, others may come with suggestions on how we can improve their experience and at the end of the day we can use the feedback to improve accessibility and usability for all.
Scores from automatic tools just reflect what the automatic tools know
The awareness of automatic tools is improving, but I still need to explain this often to people that are new(er) to accessibility – automatic tools are (currently) just static analysis based on code rules. At least when it comes to open source tools (that are then integrated in multiple services and closed source tools as well).
So, basically – we write rules to cover obvious accessibility issues in code and if our tests find such code we know we have an error.
The problem here is – besides some of the situations that can trick our rules into thinking that real problems is not a problem (false negatives) or the other way around (false positives) – that we can’t really cover all possible variations and permutations in the code out there. And another issue – our tools have bugs too.
So – a score from a tool can only mean – our tool discovered XX out of YY rules are passing. The code of your website (or app) does not include code that we consider inaccessible.
So, as an example – 90/100 basically means that our code is passing 90 out of 100 rules.
As a user, when I am not familiar with those rules and perhaps don’t know or don’t care about the code, this score means little to me. What if I am for example color blind – does this score mean that I can perceive 90/100 pages? Or 90/100 percent of any page? Or that my needs are covered in the 90 part, but if I am a keyboard user I cannot use the page?
I could go on – I hope you understand now. Scores don’t mean a lot when we don’t know what exactly is behind them.
Even when we know exactly what the rules are – we still need more information – which version of rules was used for the score? Which rules passed and which not? And so on…
So, even if we are experts of the tools used to provide the score – we need much more to understand. But – accessibility statement is not for the tool experts – it is for website or mobile app users!
What to do instead of showing a score
Some prefer listing out all Web Content Accessibility Guidelines (WCAG), at least their success criterion. That is excellent when people know about them. But once again – only listing we fail this and we pass this is of low value due to the binary nature of the pass versus fail (a single fail on a single webpage means the whole website is not conforming).
And once again – a lot of people don’t know WCAG and don’t really need to. They want to know what kind of barriers they can experience (ideally that there are no barriers, of course). WCAG listing is very useful for authorities and specialists, but it’s often not very useful for people with disabilities that need to know where they can find barriers and what to do. And when the barriers will be fixed and how to contact the site owners to get alternatives.
Think of the users first, authorities second. Accessibility statement has a lot of common grounds with Accessibility Conformance Reports (ACRs), but again – they serve different purpose. If you need an ACR (mostly for procurement usage), I suggest having it as a separate webpage, linked to accessibility statement, but not replacing it.
So – once again – showing a score is often useless. Sometimes deceiving. It shows that you use a tool, which is great, but it can also show that you don’t really understand the user perspective. It may show that you also misunderstand the purpose of accessibility statement – it’s not for authorities, it’s for users!
If you really need a score – you could use WCAG passed versus failed success criteria. But once again – this score needs much more information to be valuable. Failing a single image text alternative is failing the whole 1.1.1 Text Alternatives success criterion. In reality it may again mean a lot of things: it may be a total blocker for screen reader users to understand some content or it may only be a small issue of an unlabelled icon button. So – score is an abstraction on a level too high to be of value for users.
Please make sure you provide value – users need to know what is not working, what are you doing to fix it, how they can get an alternative – in a nutshell. It really doesn’t help if we have same open issues when years pass and the only update we did was the date of accessibility statement.
Excellent start from the Article 7 of the Web Accessibility Directive (opens in new window), to get you started on what shall accessibility statement include:
- an explanation concerning those parts of the content that are not accessible, and the reasons for that inaccessibility and, where appropriate, the accessible alternatives provided for;
- a description of, and a link to, a feedback mechanism enabling any person to notify the public sector body concerned of any failure of its website or mobile application to comply with the accessibility requirements set out in Article 4 and to request the information excluded pursuant to Article 1(4) and Article 5; and
- a link to the enforcement procedure set out in Article 9 to which recourse may be had in the event of an unsatisfactory response to the notification or the request.
Please bear in mind – some countries decided to go beyond and authorities there even require a clear timeline of when things will be remediated. This should be the minimum in my opinion, so I invite you to include it and integrate accessibility into your culture for most sustainable efforts.
