Dealing with a Third Party Accessibility Issue

It's not your code

You try not to build everything from scratch. You look for third-party platforms and existing solutions to save time and money. You find something that works, drop it into your website or app, and move on.

And it works… for most people.

Then a person with a disability files a complaint because your app doesn't work with a keyboard. The accessibility issues are serious. It feels too late to refactor away from the third party solution and you can’t fix the code or change the design because the third party controls it - not you.

But you're still responsible

When your website or app has accessibility issues caused by a third party platform, you still have responsibility because you chose to incorporate the third party platform.

State web content and mobile apps must meet WCAG 2.1 Level AA according to Title II of the ADA.

What can you do?

When you can't seem to fix a third party's code, try this:

• Remove it. Easier said than done, but sometimes it's the best choice. You might not need to remove the whole third party platform - just the feature with the problem. Ask yourself: is this feature essential for all users, or just a nice-to-have? In other words, is your minimum viable product accessible?
  • For example: if an autocomplete feature of a third party's combo box doesn't work with a screen reader, consider removing the autocomplete for everyone.
  • Another example: if a third party's table's sort feature doesn't work for keyboard users, consider turning off the sorting for all users.
     
• Swap it. A platform may be mostly accessible but still have a few parts that are not. If a component or widget has accessibility issues, look for a different option that does the same job and works for all users.
  • For example, if a platform's radio buttons are not accessible but its dropdown is, use the dropdown.
     
• Read the documentation. Find the accessibility documentation for the third party platform and read it. You may be able to resolve the issue after reading the guidance.
  • The documentation may have accessibility guidance for end users. If you find a solution, help users find it too. Add tips for hard-to-use controls, or link to the platform's own accessibility help. For example, some third party products have keyboard controls that are non-intuitive - not easy to guess, but documented. Because of that, they will pass accessibility tests even if usability is poor. Users can get by once they learn the quirks. But they need you to tell them how to use it.
  • The platform may have technical docs for developers. Sometimes, JavaScript frameworks support accessibility, but you have to turn it on. Check for settings, flags, or options to enable accessibility support.
     
• Provide an accessible alternative. Give people another way to get equivalent access to the info or functionality.
  • Example: A data visualization tool that doesn't work well with a keyboard and screen reader. Give users a way to access the information as a data table.
     
• Reach out. Check the platform's bug tracker or code repo to see if the accessibility issue is already reported. Look for discussions, planned fixes, or temporary workarounds. If a fix is planned, tell your users when to expect it. If you don't find anything, file a new bug with the platform. While you wait for the Third Party's remediation, consider other ways to help your users.
   
• Fork it, fix it. Some third party tools are open source. That means anyone can use and change the code. A developer can copy the code, fix the issue, and submit a "pull request" to show the third party the solution. Kudos to your team if you fix accessibility issues for the rest of the world!
   
• Overlay scripts. Some web developers can write JavaScript "overlay scripts" to fix issues on a page. These scripts run after the page loads and changes the HTML to fix accessibility issues. It may be enough to satisfy the needs of one user as a temporary fix, but don't expect this to be a permanent solution. Overlay scripts are often forgotten to maintain as the site's code changes.
   
• Be available. Give users a way to report accessibility issues. Make it obvious. A simple contact method can help reduce frustration and make users feel heard.
   
• Take complaints seriously. If users report issues, don't say "the vendor made it" or blame someone else. Remember, you are responsible for the user experience. Take the complaint seriously and do everything you can to help. Thank them for reporting the issue. Treat complaints like a gift. They are helping your content get better.
   
• Document everything. Keep a record of what you know and what you tried. If there ever is a legal review, showing that you knew about issues and worked to fix them looks much better than saying "we didn't know" or "we did nothing."
   
• Do accessibility earlier. In the future, consider the accessibility of the platform before you commit to using it.
  • Before you buy, ask the vendor about accessibility. Request an Accessibility Conformance Report (ACR) or Voluntary Product Accessibility Template (VPAT).
  • Research the platform's accessibility claims and promises. Use a checklist to verify those claims.
  • Test it with a keyboard.
  • Try it with a screen reader.
  • Let a person with a disability test your prototype.
  • Ask a digital accessibility expert if they have experience with the platform or other recommendations.

Content posted by a third party

If you manage a website or mobile app for the state, and a member of the public (a third party) is able to post content, such as comments, then the accessibility of that content is not your responsibility. 

However, the accessibility of the user interface that the public uses to post the content is your responsibility if you bought it or built with it.

Read more about this exception to Title II of ADA