Customer Support Pathway

What it means in practice

Offer at least three contact channels: email, chat, and phone. Email and chat work for deaf users and for users who find phone calls difficult. Phone needs to be reachable through a relay service in countries that have one, and ideally through real-time text where the underlying network supports it. For live chat, use a tool that's actually accessible. Most embedded chat widgets are accessibility nightmares — keyboard traps, missing labels, no live region for incoming messages. Test your chat widget with a screen reader before you deploy it. If it fails, replace it. There are accessible alternatives out there. For phone support, the EU's national relay services let deaf users call hearing agents through a sign language or text intermediary. Your contact page should mention them and link to the local service for the user's country. Don't assume users know they exist. For video support (becoming more common in financial services and healthcare), real-time captioning is the minimum. Sign language interpretation is the gold standard but expensive. Partner with a remote interpretation service if you serve sign language users in volume. Response times matter. A user who has to wait three days for an email reply because chat is broken for them is being treated as a second-class customer. Match response times across channels — if chat is two minutes, email shouldn't be three days.

Common pitfalls

• ×An inaccessible chat widget that screen reader users can't operate. The most common support accessibility failure I see by a wide margin.
• ×Phone-only support with no email, chat, or relay alternative. Deaf and hard-of-hearing users have no way in at all.
• ×Different SLAs across channels, where the accessible channels (email, chat) somehow have slower response times than the inaccessible one (phone).

How to verify it

Test every contact channel with a screen reader. The email form should be properly labelled, the chat widget should announce incoming messages, the phone number should be reachable through relay. Audit your response time data by channel. If email is meaningfully slower than phone, you have an equity problem dressed up as a priority decision.

What it means in practice

Treat the help centre as a first-class part of the product. Same accessibility standards, same testing, same release process. The thing that goes wrong is when the help centre lives on a separate platform — Zendesk, Notion, GitBook — that the engineering team forgets about. Audit it at least quarterly. Write help articles in plain language. Aim for the same readability targets as your customer-facing copy: Flesch-Kincaid 60-70, sentences under 25 words, paragraphs under 100. The user reading a help article is already frustrated. Don't make them work any harder than they need to. Use step-by-step structures with headings, numbered lists, and screenshots. Every screenshot needs alt text describing the action it illustrates, not 'screenshot of settings page'. Try: 'Settings page with the Notifications toggle highlighted in the off position'. For video tutorials, captions are mandatory. Auto-captions are a starting point. Review and edit them before publishing. Provide a transcript on the same page as the video so users who prefer reading don't have to scrub through the playback hunting for the bit they need. Document the accessibility features of your product explicitly. A page titled 'Accessibility features' that explains keyboard shortcuts, screen reader compatibility, contrast options, and how to report issues serves disabled users directly and satisfies Clause 12.1 in writing.

Common pitfalls

• ×Running the help centre on a third-party platform that nobody audited for accessibility. The platform's defaults are often inaccessible and you ship the gap on top.
• ×Screenshots with no alt text. Every step in the article that depends on a screenshot is now invisible to a screen reader user.
• ×No 'Accessibility features' page. Users who could be using your product happily if they knew about the keyboard shortcuts give up because nobody told them.

How to verify it

Run the help centre through axe-core or Lighthouse. Run a screen reader through three or four representative articles. Try to navigate the help centre by keyboard alone. The standards are the same as for the main product, no exceptions. The Support & Documentation Checklist on this site covers the Chapter 12 requirements clause by clause. Use it to audit the help centre at least once a year.

What it means in practice

Set up a dedicated accessibility inbox (something like accessibility@yourcompany.com) and route it to a real person, not a black hole. Every accessibility complaint should be acknowledged within 24 hours and triaged within five working days. The triage question: is this a real bug, a misunderstanding, or a known limitation? Real bugs go into the regular bug tracker tagged as accessibility, linked back to the original complaint. Misunderstandings get a response with the workaround or the relevant help article. Known limitations get an honest response: 'This is a documented limitation in our accessibility statement, the workaround is X, we plan to address it in Y.' Keep the user in the loop. Send a status update at least every two weeks while the fix is in progress. Complaints escalate because of silence — users who feel ignored go to the regulator. Users who feel heard tend to wait. Log every complaint in a register: date received, date acknowledged, user (anonymised), issue, severity, status, owner, resolution, resolution date. That register is your evidence trail. When the regulator asks how you handle accessibility complaints, the register is your answer. For critical bugs that hit a core flow for a lot of users, the response should be quick and visible. A fix or workaround in the next release, communicated proactively to anyone who reported related issues. That's brand-protective as much as it's compliance-driven.

Common pitfalls

• ×An accessibility inbox that nobody is monitoring. Complaints sit there for weeks and the user goes to the regulator.
• ×Treating accessibility complaints as feature requests competing for backlog priority. Compliance bugs are a different category and need a different priority.
• ×Closing complaints as 'won't fix' with no explanation. Users who get a clear 'no' with a reason often accept it. Users who get a silent close almost always escalate.

How to verify it

Pull last month's accessibility complaints from the register. For each one: acknowledged within 24 hours? Triaged within five days? Communicated back to the user with a plan? Mostly no? The workflow exists in name only. The Compliance Programme Template on this site includes a complaint handling workflow you can adapt to your team. The User Testing Log is the right format for documenting individual user reports with reproduction steps.