Four Questions Your Website Accessibility Statement Should Answer

By Jules •

Your accessibility statement is not just another contact form on your website.

So you put an accessibility statement up on your website, and now you’re done, right? Not exactly. It won’t magically protect you from litigation if feedback from users disappears into a virtual black hole. Your accessibility statement should be a living document that is most effective when you also make a few key changes to your organization’s regular processes. Here are five things to consider as you launch your accessibility statement.

A well-crafted accessibility statement answers several questions:

  1. What standard is your organization using to measure accessibility?
  2. How do you get feedback about the accessibility of your site?
  3. Who is responsible for responding to accessibility issues found by users?
  4. And how does your organization handle accessibility fixes?

1. What standard is your organization using to measure accessibility?

Is your site far from being WCAG 2.1 AA compliant? That’s ok. It’s necessary to have a bold vision for accessibility, and in order to get there, start by setting realistic and achievable goals. Begin by reviewing and improving new content and key user experiences. Include a statement about the accessibility of older articles, or other known issues, so people know what to expect. If you need time to work through accessibility issues, that’s fine. Start with progress over perfection.

Don’t know where to start? Contact us to talk accessibility strategy. We can help with an Accessibility Review, implement key accessibility improvements, and quickly turn needed changes into spec’d tickets for developers.

2. How do you get feedback about the accessibility of your site?

Make sure your website has an accessibility page that includes an email address or a contact form. It should be clear to your visitors how they can submit feedback, and when they can expect follow-up.

The goal of an accessibility page is to create an open, transparent dialogue about where your organization is in the accessibility process and to ask for feedback about ways to improve. If people submit feedback and never see an improvement on the issue, they might use litigation to inspire action. If they submit an issue and never hear back at all, you’ve lost trust with your audience and created a negative user experience. On top of that, you’ll continue fielding emails or phone calls about the issue until it’s resolved. A good feedback process saves you time, boosts user confidence, and proactively fixes accessibility issues.

3. Who is responsible for responding to accessibility issues found by users?

Depending on the size of your organization, you might have one person or a whole team reviewing feedback from users. The important thing is that everyone is on the same page. Have a clear, documented process outlining how accessibility feedback is prioritized and queued up to be fixed. Include timely, transparent communication with the person who shared the feedback as part of your process.

For a lot of our partners, we recommend having a dedicated person or team to maintain oversight, but as long as issues are documented, moved into the queue, and follow up is complete, you can create a process that makes the most sense for your organization.

4. And how does your organization handle accessibility fixes?

Accessibility issues need to be prioritized and added to the queue. Here at ThinkShout we use GitHub to track issue progress. Next, delegate this task to an accessibility team or point person, identifying that this task is urgent and high priority.

Depending on the issue, the time it takes to fix could vary. It’s good practice to reach out to the person who documented this issue with an estimated, realistic timespan of when your team will be able to fix the issue. If something is too large to fix immediately, see if there’s another way you can provide access to the person who submitted the request, and update your site making the alternative broadly available until you’re able to resolve the issue. (For example, this would be a work around for a third-party job application form that’s not accessible, but at the top there’s an accessible link to an email application process that accomplishes the same user goal.) Once the fix has gone live, reach out to that person for the last time letting them know the issue has been fixed, and let them know you’d love feedback if they decide to test it out.

The time to fix things will vary. That’s OK. As long as you’re committed to fixing the issue, and keeping a clear line of communication with the person who documented it, you’re doing well.

Accessibility is a team effort.

Organizations need to create a process that makes the most sense for their size, structure, and workflow. The important thing is to make sure your process is clear, so resolving accessibility issues is streamlined for your team.

Here’s an example process:

  • Follow up quickly (within 3 business days) so your site visitors feel heard, and let them know that you’ll be addressing the issue.
  • Update the accessibility policy page with known issues so other visitors don’t reach out to document the same bug.
  • Get the issue into the queue. For our partners, we use GitHub to add tickets and tag them with ‘high priority’ and ‘accessibility’ so they can be delegated and addressed in a timely way.
  • Follow up with the person who submitted the issue once it’s resolved. This will build trust, close the loop, and allow for user testing. Ask if they’d be willing to take a look and share any additional feedback.

In Accessibility for Teams in a Hurry, we talk about how accessibility is not one person’s job–everyone has a role to play. You can have one person dedicated to moving accessibility issues forward, but if you dedicate one person to accessibility while another team is creating designs, code or content elsewhere you’re going to continue to create a steady stream of new accessibility issues, and you’ll find yourself taking two steps forward and one step back with each new update.

Incorporating accessibility into your existing process with your broader team is the best long-term solution. If you have developers on staff, they should be testing their code for accessibility before it goes live. Anyone adding content to the site should be reviewing their contributions for accessibility, as well.

If you’re interested in making your website more accessible, or looking to work with a team where accessibility is woven into strategy, design and development, we’re here to help!

Get the conversation started.