Zendesk Guide Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-07-27
Zendesk Guide is the help center and knowledge base side of Zendesk, and it occupies an awkward position in most companies' accessibility programs: it is customer-facing, it is often the first place a frustrated user goes, and almost nobody audits it. The marketing site gets reviewed, the product gets reviewed, and the help center quietly runs a theme somebody forked from the default Copenhagen template three years ago and has not merged upstream since. That matters more than it sounds, because Zendesk maintains Copenhagen as an open-source theme and ships accessibility fixes into it over time; a fork that has not been updated is frozen at whatever state the theme was in on the day it was copied, including whatever focus, labeling, and landmark problems existed then. The second half of the problem is the articles themselves. Help center content is written by support agents and product specialists who paste from Word, Google Docs, Confluence, or a previous ticket, and pasted content arrives with visually styled pseudo-headings, images dropped in without alt text, tables built for layout, and occasional raw HTML for accordions or tabs copied from a snippet library. The Guide editor will happily publish all of it. There is a compliance dimension too. Under the European Accessibility Act, support services connected to a covered product or service are expected to provide information in accessible modes of communication, which puts help center documentation squarely in scope rather than treating it as optional marketing collateral. Enterprise buyers increasingly ask for accessibility documentation covering the support experience as well as the product. This checklist covers both the theme layer and the article layer, because fixing one without the other leaves the help center broken.
Common Accessibility Issues
Most customized help centers began as a copy of the default Copenhagen theme, which was then edited for branding and never merged with upstream again. Zendesk continues to improve the open-source theme, including accessibility fixes to navigation, focus handling, and labeling, and none of those reach a fork. Worse, the customization itself often removes semantics: a nav element replaced with styled divs, a search landmark dropped during a redesign, or an icon-only button whose accessible name was lost when the markup was rewritten.
Compare your live theme against the current open-source Copenhagen theme and pull in the accessibility-related changes rather than treating the fork as frozen. Keep a record of exactly what you changed from the base theme so future merges are tractable. When customizing, preserve semantic elements and landmarks instead of replacing them with divs, ensure every icon-only control keeps an accessible name, and re-test navigation, search, and the article page with the keyboard after each theme change, since theme edits are the single most common way accessibility regressions enter a help center.
Help center articles are dense with screenshots, and the Guide editor does not require alt text when an author inserts an image. Because screenshots in support content usually carry the actual instruction, showing which button to press or what an error dialog says, an unlabeled screenshot is not a cosmetic gap; it is the missing step. Screen reader users hear a filename or nothing at all and cannot follow the procedure, which is particularly harsh in a help center, where the reader is already stuck.
Write alt text that conveys what the screenshot demonstrates in the context of the step, not a description of the interface chrome. For a screenshot showing where a setting lives, describe the location and the setting rather than saying screenshot. Better still, make the procedure work without the image by writing the steps in text and treating the screenshot as reinforcement, which also helps people on slow connections and anyone skimming. Add an alt text check to your article review process, and audit existing high-traffic articles first, since a small number of articles usually account for most of the traffic.
Support articles are frequently pasted in from other tools, and the paste brings visual styling rather than structure. Section titles arrive as bold paragraphs with inline font sizes, or as an arbitrary heading level chosen for size, so a long troubleshooting article ends up with no navigable outline or with a jump from a second-level heading straight to a fourth. Screen reader users navigating by heading, which is the standard way to find the relevant section of a long article, land on nothing useful and are forced to read the whole page linearly.
Paste as plain text and then apply the editor's heading styles, or clear formatting after pasting so inline styles do not survive. Establish a simple house rule: the article title is the top-level heading, major sections sit one level below it, and subsections one level below that, with no skipping. Review your longest and most trafficked articles for heading structure first, and consider adding an in-page table of contents for long procedures, which benefits everyone and forces the heading structure to be correct in order to work.
Help center search is the primary navigation for most visitors, and search interactions frequently update the page without telling assistive technology. Instant suggestions appear beneath the search field with no announcement of how many results are available or how to reach them, and a results page that updates in place gives no indication that the content changed. A screen reader user types a query, hears nothing, and has no way to know whether results appeared, whether there were none, or whether the search failed.
Ensure the suggestion list is exposed with an appropriate combobox pattern so the number of suggestions and the currently highlighted option are announced, and that arrow keys move through suggestions with Enter selecting one. Announce result counts and empty states through a live region so that a change in results reaches a screen reader user without them having to hunt for it. Confirm the search field itself has a real label rather than a placeholder alone, and test the whole flow with the keyboard from the field to a selected result and back.
Authors collapse long articles using accordion or tab snippets copied from a code sample or an internal template, and those snippets are almost always divs with a click handler. The result is a control that cannot be focused with the keyboard, does not announce whether it is expanded or collapsed, and hides content that a screen reader user has no way to reveal. Because collapsed sections often contain the actual answer, this turns a navigational nicety into a hard block.
Use real button elements for accordion triggers, wire them so they are reachable by Tab and operable with Enter and Space, and expose the expanded state and the relationship to the panel they control so it is announced. For tabs, implement the standard keyboard behavior with arrow keys moving between tabs. Where you cannot control the markup being pasted into articles, the safer answer is to stop using collapsible sections in help content entirely and rely on headings and a table of contents instead, which is accessible by default and easier for everyone to scan.
The submit a request form is the escalation path when the help center does not answer the question, so a failure here means the customer cannot reach support at all. Common problems include custom ticket fields whose visible label is only a placeholder that disappears on typing, required fields that are marked with color or an asterisk alone, dropdowns without an accessible name, and validation errors that appear visually near the field but are never announced or associated with it.
Give every ticket field a persistent visible label that remains after the user starts typing, and use the placeholder only for an example of the expected format if at all. Mark required fields in text as well as visually, and make sure the requirement is programmatically exposed. When validation fails, associate each message with its field, describe what to correct in plain language rather than saying invalid input, move focus to the first error or announce a summary through a live region, and confirm that the error is reachable by keyboard from the field it belongs to.
Zendesk Guide-Specific Tips
- Diff your live theme against the current open-source Copenhagen theme and pull in accessibility fixes, since a fork stops receiving them the moment it is created.
- Paste article content as plain text and then apply heading styles, because pasted formatting is the main source of fake headings.
- Fix your top twenty articles by traffic first; help center traffic is heavily concentrated, so a small remediation pass covers most real usage.
- Prefer headings and an in-page table of contents over collapsible accordions in articles, which avoids the div-based widget problem entirely.
- Test the search field, the suggestion list, and the submit a request form with the keyboard after every theme deployment.
Recommended Tools
Copenhagen Theme (open source)
The source of the default Zendesk Guide theme, useful for comparing your fork against current markup so you can identify and re-apply accessibility improvements your customized theme never received.
axe DevTools
A browser extension that audits a rendered help center page for missing accessible names, contrast failures, form labeling problems, and non-semantic interactive elements introduced by theme customization or pasted article HTML.
NVDA
A free Windows screen reader for confirming that search results and suggestions are announced, that accordions expose their state, and that request form errors are actually communicated rather than only displayed.
Frequently Asked Questions
Does the European Accessibility Act cover our help center?
In most cases yes. The EAA covers a defined set of products and services, and it also addresses the support services attached to them, expecting information about the service to be provided in accessible modes of communication. A help center is the primary way most companies document how their service works, so treating it as out of scope because it is not the product itself is a risky reading. Practically, the help center is also where a customer who has hit an accessibility barrier in the product goes for help, which makes an inaccessible help center a compounding failure. If your organization sells covered products or services to consumers in the EU, audit the help center alongside the product rather than after it. This is general information, not legal advice.
We use a customized theme. Where should we start?
Start by comparing your theme against the current open-source Copenhagen theme, because a fork stops receiving Zendesk's accessibility improvements the moment it is created, and a theme copied years ago is frozen at that point. Look specifically at whether customization replaced semantic elements and landmarks with styled divs, whether icon-only controls kept their accessible names, and whether the focus indicator survived the branding pass. Then move to content: audit your highest-traffic articles for missing image alt text and fake headings, since help center traffic concentrates heavily in a small number of articles and fixing twenty of them covers most real usage. Finally, test the search field, the suggestion list, and the submit a request form with the keyboard alone, as those three flows carry the most consequence when they fail.
Further Reading
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.