In this section you can provide the minimal set of information recommended for your accessibility statement. This includes information about your organization, the accessibility standards you applied, and your contact information for feedback.
Here you can enter the name of your organization, and the web address and name of your website or mobile application. For mobile applications, include version information and the release date, to identify a specific version.
Which accessibility standard have you been following? The Web Content Accessibility Guidelines (WCAG) is internationally recognized. The latest version is WCAG 2.1.
To what degree do you conform to the accessibility standard stated in the previous section? Sometimes there are justifiable reasons to not fully conform. You can indicate parts that do not yet fully conform, including guidance on how users can find help, in later sections of this form.
Sometimes you may be applying more accessibility requirements than those specified in the accessibility standard stated above. For example, you may be providing sign language videos or context-sensitive help for functionality. Here you can list these additional accessibility requirements.
Example: “Although our goal is WCAG 2.1 Level AA conformance, we have also applied some Level AAA Success Criteria: Images of text are only used for decorative purposes. Re-authentication after a session expires does not cause loss of data. Some videos have sign language interpretation.”
In which ways can users can get in touch with your organization when they encounter an accessibility barrier? Ideally you should provide more than one option. Also indicate the duration after which users can expect a response from your organization.
Providing a date helps users to understand if the accessibility statement is being actively maintained or outdated. Ideally the date of an accessibility statement should not exceed one year, or it may be considered unmaintained. Writing out the month makes the date clearer internationally (eg. "1 February 2019" rather than "01/02/2019", which is ambiguous).
In this section you can describe the efforts your organization takes to ensure accessibility. This helps users to understand your sincerity and the validity of the claims you make in your accessibility statement.
In this section you can provide more technical details to help users understand any issues they may be observing. This includes information about compatibility with web browsers and assistive technologies.
There are many situations in which limitations to accessibility can occur. For example, you may not be able ensure instant accessibility of user-generated content. Providing transparency on such situations helps users to understand any issue they may be observing, and to find alternatives where applicable. Under the EU Web Accessibility Directive, public bodies are required to provide information on the parts of the content that do not conform, the reason for not conforming, and, if applicable, where to find accessible alternatives.
List the content parts that have accessibility limitations, a description of the issue that may be observed by users, a brief explanation of why the issue occurs, and what to do in the mean time, such as who to contact or where to find accessibility alternatives where appropriate.
Despite best efforts, accessibility may not work well in every combination of operating system, web browser, and assistive technology. Developers typically test their websites and mobile applications with common user environments, to determine compatibility. WCAG defines requirements for accessibility features provided by content authors to be accessibility supported. Communicating this compatibility expectation helps user to determine if that is the cause for any issues they may be observing.
Describe the environments (combinations of web browsers, assistive technologies, and operating systems) that the content is expected to work with. These should be in-line with the WCAG definition of accessibility supported use of technologies.
Help users understand what versions of operating systems, web browsers, and assistive technologies are not (or no longer) supported. This helps user to determine if they can use your website or mobile application with their current environments.
Describe the environments (combinations of web browsers, assistive technologies, and operating systems) that the content is not expected to work with.
You may be relying on specific web technologies, such as JavaScript, WAI-ARIA, or SVG to ensure accessibility of your content. Communicating this expectation in the accessibility statement can help users to understand the reason for issues they may be observing. For example, the accessibility features may not work because the user disabled JavaScript. The WCAG 2 conformance requirement 4 on "accessibility supported was of using technologies relied upon" provides more background.
Describe the technologies that are relied upon for conformance. The content would not conform if that technology is turned off or is not supported.
How did you assess your website or mobile application, to determine the information provided in the previous sections? This helps users understand your quality assurance process and the background for the claims you make in your accessibility statement.
Provide links to related background and evidence to support the claims you make in this accessibility, and to provide more transparency and credibility. This can include an evaluation report, an evaluation statement, or a certification.
An evaluation report provides details on which accessibility requirements are met, and which are not. While this is usually more technical of nature than the average user, it can help some users to understand issues they have been observing. You can use the WCAG-EM Evaluation Report Tool to create an evaluation report. Place the link to the report here.
An evaluation statement summarizes the essential outcomes of an evaluation report. The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) defines requirements for evaluation statements in Step 5.c of the document. This can be provided instead of or in addition to an evaluation report provided above.
In this section you can add information about the formal approval of this accessibility statement and, if applicable, any complaints escalation procedure.
In some situations you may want to or may be required to provide information about a formal complaints procedures. For example, a quality management process within your organization may require you to establish a formal complaints procedure with clear escalation paths. The EU Web Accessibility Directive foresees EU countries to have legal “enforcement procedures” when users are not satisfied with the responses from public bodies. Inform users about any such formal complaints procedures. This may also motivate them to provide you with valuable feedback about the accessibility of your content. Example: “We aim to respond to accessibility feedback within 2 business days, and to propose a solution within 10 business days. entity], should you be dissatisfied with our response to you.”
Your organization may want to formally approve this accessibility statement, for example for internal purposes or to show users that this is part of the corporate policy.