This is a repost of an old article on the Tenon blog. Since that’s being sunsetted, I’m reposting it below.

During one of our recent sales meetings, one of our sales staff informed me that one of his customers had asked us to create an accessibility statement that they could put on their website. So, I wrote this post to document my thoughts along the way.

General principles

Before we begin, we need to understand why we’re making the accessibility statement in the first place – it is not so we can cover our butts, legally (unless you’re in the EU). Frankly, the single best way to cover your butt is to have an accessible website. In fact, you may even be able to render a plaintiff’s claims to be moot simply by fixing the problems on your site (Carroll v. New People’s Bank, Inc.). That said, your accessibility statement can be a clear demonstration to would-be litigants that you take this stuff seriously, that you’re actively working to improve, and that you’re responsive to user needs.

Your accessibility statement should be a clear, transparent, and informative statement documenting your commitment to ensuring accessibility for your customers with disabilities and how they can reach you in case they have problems.

Core components

Introduction

The introduction of your accessibility statement should present the document and describe its scope and contents. Something like:

[Company Name] is committed to ensuring accessibility to our website and associated systems for customer
service and support. This document describes our efforts relating to compliance with local and national
law and conformance with international standards for Web Accessibility.

This statement includes a description of our past, current, and efforts in accessibility, contact information
for responsible parties, and, our current conformance status, and known issues and workarounds for those issues.

Contact Information

I’m of the opinion that the next section after the introduction should be the contact information for customers
who may be experiencing problems. Placing this early in the document demonstrates an openness to feedback from
customers. You should provide contact information for technical support, sales support, and a specific person
tasked with accessibility.

Customers requiring assistance with purchasing or renewing service can email sales@example.com or call, toll-free 888-555-1212

Customers needing technical assistance can email support@example.com or call, toll-free 888-555-2121. You may also find accessibility help on our customer forums at https://example.com/support/. Use search “accessibility” to see possible discussion of the accessibility of our website and online services

For direct assistance or for accessibility issues not covered here, please email Lori Driver at lori.driver@example.com or call 202-555-0157 during normal work hours

Naturally, the above language makes a couple of promises that you’re obligated to keep:

1. That you have an actual point-of-contact responsible for handling the needs of customers with disabilities. This doesn’t necessarily have to be a single person, but it should be a place that responds quickly and decisively to accessibility issues.
2. That your sales and customer support staff are adequately trained and prepared to support customers with disabilities.

What are you doing to support and improve accessibility?

Next, you’ll want to provide some background on what you’re doing to support and improve how you serve customers with disabilities.

[Company Name] began an organization-wide project to improve how we serve customers with disabilities in 2019. Below is a timeline of our efforts:

• 2019
  • Added accessibility to our mission statement
  • Held 2 training events for management and executives on integrating accessibility into our processes
  • Began biweekly lunch-and-learn sessions for customer service, sales, and tech support staff.
  • Held a week-long bootcamp style training for design, development, and QA staff.
  • Had a third-party audit performed on 12 core user flows within our primary web property.

Current conformance status

In the next section, you’ll want to disclose to customers what your level of conformance is. This is definitely something that needs the input from your legal counsel, as they may want to weigh in on the amount of disclosure provided in this section:

The audit, mentioned above, identified 75 distinct error patterns on this site which impact our compliance with
WCAG 2.1 Level AA:

• 52 of the errors have been remediated and have been retested and verified by the same firm which performed the audit
• 14 of the errors are the result of third-party widgets made by Initech. We have notified them of the results of the audit that pertain to their code and have given them until the end of the year to repair the issues or we will seek an alternate solution
• 9 issues remain outstanding. They are listed in the following sections. Workarounds, if any, are provided.

The most important thing to take into consideration in this section is that it be honest and accurate. In particular, the last thing you want to do is to claim conformance when you aren’t, because doing so tends to invite more scrutiny, not less. At the same time, this level of transparency demonstrates that you’re making positive progress to improve the experience of customers with disabilities. The caveat, however, is that you actually follow through with the improvement.

Known issues and workarounds

In my opinion, this is where you can really demonstrate for users that you care about providing them excellent service.
The reality for many users with disabilities is that most websites present hurdles and that documenting how they can
work around the challenges on your site will go a long way toward showing that you’re aware of their needs and want
to help them be successful users of your system. So, for each high severity issue, provide clear information to the user
on how they can handle their challenges.

1. Inaccessible tooltips: Forms on the website have tooltips to assist in providing helpful information on how to fill in the fields on the form. These tooltips are not programmatically associated with the field(s). In many cases, the tooltips do not contain critical information. However, in other cases they do. The information they provide will be presented as part of the error message presented at the top of the page when validation errors are present. Users can look for the heading “Errors are preventing successful submission of this form” after they’ve submitted the form, and each form field in error will be listed alone with a description of each error.
2. Text overlaps at 400% zoom on small screens This issue is specific to WCAG 2.1 1.4.10. Our UI contains a significant number of traditional HTML tables which have several columns of data and other items which reflow poorly at 400% zoom, including overlap. There is presently no known work around for many of these issues. Users of ZoomText on Windows and zooming features on macOS have no known issues.

etc. …

By documenting the issues you’re aware of and any known workarounds for those issues, you’re declaring that you’re
aware of the challenges users may face and how they can (or cannot) overcome them.

Conclusion

There are plenty of things to include in an Accessibility Statement, including things not mentioned here.
Ultimately, your goal should be to inform users about what you’re doing, how you’re doing, and who is doing it.