I have now evaluated some simple and complex websites, and even a whole banking digital presence and will just note some lessons learned here. The geography was Scandinavia and therefore EU non-EU countries (Finland, Norway, Sweden).
Accessibility statements are similar, but also a bit different
Accessibility statements are now required due to Web Accessibility Directive and therefore needed in all EU countries. Norway is still working on the implementation of WAD into it’s laws, so at the time of this writing accessibility statement is not a requirement, but they are advertising it’s soon-to-be implementation, so just a matter of few months I guess.
The peculiar thing here is that each country can have it’s own form for accessibility statements, although all of them are derived from WAD requirements. It come as a little surprise for me, but after investigating the details it may not be so strange – WAD is a minimum that each country has to implement, so if countries decide for some other requirements, then it will most probably also reflect on the statement.
Tools for accessibility statements are helpful but still not there yet
I’ve missed the possibility for importing for example. Especially when I found some additional issues and wanted to report them – and it was not possible to change the WCAG success criteria order for example. Easy to fix in the HTML that is generated but still it is obvious that tools need some more testing and feedback. There are also some user experience glitches when it is possible to delete items without confirmation.
So please be careful, maybe use another document as the source.
I hope future improvements will solve these problems, but it is no show-stopper. I’ve managed to get through quite well at the end.
Translations or native speakers need to know some technical vocabulary
I had to make a statement for the Finnish webpage and of course I wrote it in English and asked client to translate it. There are some technical terms that have to be properly translated and I must confess that I do not trust Google Translate for proof-reading. So I hope that translator got my points and tried to also interpret them as I meant.
Accessibility statement itself must also be accessible
It is easy to make some CMS related mistakes with heading levels and other semantics, so be sure to double check it when done. The generator normally produces quite good semantics, but when content is moved to your CMS it can produce some issues.
Customer support must be aware of accessibility statement
One of main goals of accessibility statement is the channel for end-users and in medium and larger companies those messages normally arrive to customer center. Therefore it is crucial to have at least basic routines established, so that we do not breach required time limitations set by WAD (normally 14 days).
Remember – accessibility statement should be a live document
Whenever something change from code or content perspective – we risk to breach some WCAG success criteria. Therefore it is crucial to have a good procedure that prevents it and at the same time also a procedure to update the accessibility statement when needed. The same goes for fixing accessibility issues – we must make sure statement is updated as soon as possible.
Statements are useful
I see the benefits allready – we need first to evaluate our accessibility. Then we must make sure to kick-off internal procedures to assure compliance. It can be a wake-up call for many and it is a very good thing. Pro-activity is the most important thing that can lead to better accessibility.