Accessibility statements are something very hot at the moment, even hotter here in Norway were I am living for the past nine years. It’s because Web Accessibility Directive (WAD) was a bit late in Norway and now all public sector websites need to have an accessibility statement before first of February 2023.
I believe accessibility statements should be the norm for all webpages and mobile applications
Before I reflect on the usefulness I have to point out that I really think we should have accessibility statements everywhere. This can be a bit strange to read but when we think about all the (cookie) consent overlays we are forced to go through (and often never read) it would make more sense to me to have an honest accessibility statement available for anybody interested.
I won’t go into details about my opinion on cookie consents, let’s just say that I believe they should be managed by the user agent (browser) and not manually, site per site. It reminds me of accessibility overlays when I think about them.
If webpages and native apps had honest and up-to date accessibility statements it would cause multiple benefits:
- people with disabilities would be able to check in advance what kind of problems they could expect, if any,
- if company works or plans to work with public sector they could be a better choice with better accessibility as a supplier,
- company transparent about their accessibility situation and plans to fix issues would for sure benefit from positive effects on its branding,
- people wanting to be employees of such companies would know about companies inclusion efforts and could prefer such companies as future employers.
But, all this is based on couple of prerequisites. I will try to describe them in following sections.
What should we expect from accessibility statement to consider it useful?
Back to main question of this post – How are accessibility statements supposed to be useful? Well we can make an accessibility statement just for the sake of it, or we can make it really useful for people with disabilities.
People with disabilities prefer that things are accessible. That they just work. But currently majority of websites and native applications are not accessible. Some accessibility problems present themselves as tiny details and are only small glitches for groups of people with disabilities and other are major barriers that block people out. So not all accessibility problems are show stoppers. On the other side we can also conform to WCAG and still be inaccessible. So WCAG is not a guarantee that site or app is accessible. It’s just a set of guidelines that helps us deliver more accessible products. But it’s not the goal to conform to WCAG, it is an indication.
WCAG standard is being used in laws. Because we don’t have a better set or rules and guidelines for accessibility. So it can give us kind of indication what is supposed to work and what not.
But on the other side – not all people are familiar with WCAG. It’s quite a narrow group of people. Luckily the group is growing, but we can’t just refer to WCAG audit to make an effective accessibility statement. It can help for users that know about WCAG but majority will not study our accessibility statements to get information about what problems they may experience.
That’s why the whole point of accessibility statements isn’t to list all WCAG problems, but it is more to list what kind of problems can people with disabilities have. And more importantly how are we planning to solve them and what do we offer as an alternative.
Accessibility statement requirements of Web Accessibility Directive are well known now (opens in new window). Accessibility statements shall include (shortly summarized):
- explanation concerning those parts of the content that are not accessible,
- reasons for that inaccessibility,
- where appropriate, the accessible alternatives provided instead,
- possibility for people to give feedback about problems they may have,
- information about possibilities to complain if site/app owners response was not satisfactory.
Once again – from end users perspective – it doesn’t matter what WCAG success criterion site fails. End users need information about barriers and how to overcome them. They need to know if their screen-reader will work on the page. If they will be able to read the captions on the video. If they will be able to zoom in on the page. If their browser settings for large fonts will be respected. And so on.
It helps, of course, to have a “checklist” and to check that we didn’t forget to test somethings. And most effective way to do it is still WCAG. But it’s not the point of the accessibility statement to copy paste audit findings. The point is to inform users about problems, how we offer to help them and also very important what are we doing to fix them.
That’s why accessibility statements also need to be updated at least once per year. Companies serious about accessibility will most certainly update them way more often. I like to think that accessibility statement could potentially be updated at the end of each release cycle. And in these agile days it could even mean daily.
So to close it up – useful accessibility statement is only useful when it is useful for people. People with and without disabilities. Accessibility statement is not a statement for authorities to leave us alone. It’s about being honest about problems and being proactive on fixing them while in the meantime offering people help. Help that would not be needed if we could have website or app accessible in the first place…