With Web Accessibility Directive implemented into all European Union countries we should expect at least all public sector websites to have an accessibility statement (opens in new window). Some non-EU member states like members of the European Free Trade Association (EFTA) are also in progress of implementing the WAD, so we will soon get accessibility statements in all European countries.
The purpose of accessibility statement
Purpose of accessibility statement is by now probably known;
- declare what may not be accessible (WCAG 2.1 A and AA level and there are some minor differences in different countries), provide accessible alternatives when possible,
- show that organization is actually implementing accessibility,
- define contact point for accessibility questions and eventual complains.
Accessibility statement design
WAD is also defining a template for the accessibility statement, and countries did actually even choose to adapt the template a bit further, so it is smart to check specific country template before documenting the content. There are also some WCAG evaluation methodology templates that can be helpful, but we must respect each countries best practices to be confident that we are doing it right.
Some of my suggested best practices
- First thing first – the statement is not only an ornament – it should be primarily useful for the end user and the authorities as well. So try to explain technical issues in both plain and specialist tone, ideally we should include technical details as a separate document that we link to.
- It is best to have a link in the footer that links to an accessible accessibility statement in HTML format. Then it is easier to update it and make sure the statement itself is also accessible.
- When just starting with a brand new accessibility statement and maybe waiting for a completion of evaluation – please make a placeholder page that already offers some explanation and a means of contact.
- You can provide an contact form(accessible of course) for the contact path but it is enough to state an email address as well. The important thing is that it will be answered and do not wait for the 14 day limit for the answer – try to help early and also important: try to prevent help is needed. You can for example build a backlog based on the items that are most frequently asked, and if possible also provide a prevention means.
- When listing and explaining the non-accessible parts try to prioritize the parts that are directly influencing user experience and concentrate less on the minor errors that can be fixed quickly (but do fix them).
- Accessibility statement should be updated more often that only once per year. This is especially important if there are major changes to the website and the goal is also to improve things that were maybe not accessible before. Try not to mention deprecated technologies.
- Please do not abuse the disproportionate burden instead of doing a real accessibility evaluation. It should only be used when you can prove it.
With time and experience I will surely make few more posts about this subject but this should be a pretty good start.
Additional resources
- Developing an Accessibility Statement by W3C (opens in new window),
- Amazing report about quality of accessibility statements in the United Kingdom (opens in new window).
