Drupal theme accessibility checks are cheapest when they happen against real site patterns, not a polished mockup. A theme can look compliant in isolation and still fail once menus, fields, view modes, forms, and editor-created media are added.
The goal is to catch the patterns that multiply. One inaccessible card template can appear on a listing page, a related-content block, and a landing page. Fixing it before content entry is usually simpler than cleaning up dozens of pages later.
Test Drupal Output, Not Just Components
Start with rendered Drupal pages that include real field labels, taxonomy links, pagination, media embeds, and administrative edge cases. Component-library checks matter, but Drupal teams also need to see how templates behave when content is long, empty, translated, or reordered.
For example, a card component may have a visible title and an image. The weak version wraps the image, title, and teaser in separate links with repeated text. The better choice is one meaningful link target, a useful heading level, and image alt text that does not repeat the adjacent title.
Drupal Theme Accessibility Checks Table
| Check | Evidence | Next move |
|---|---|---|
| Keyboard path | Menus, accordions, search, filters, and exposed views can be reached and exited by keyboard | Fix focus order and visible focus before content migration multiplies the pattern |
| Heading structure | Rendered landing pages and listings keep logical heading levels after blocks are rearranged | Adjust templates or editor guidance so page structure survives real assembly |
| Forms and errors | Webforms, login screens, search, and exposed filters announce labels and errors clearly | Repair labels, descriptions, and error summaries in the Drupal layer that outputs them |
| Media and cards | Images, captions, linked cards, and teasers avoid duplicated or empty accessible names | Set theme rules and editorial defaults before launch content is entered |
Use Drupal And Accessibility References Together
Drupal teams should keep the Drupal accessibility coding standards close while reviewing theme output. The Drupal accessibility gate is also useful because it shows the project-level expectation that accessibility is not a final cosmetic pass.
Drupal Pixels already covers theme planning in the Drupal theme planning checklist and component systems in the component library planning checklist. This audit is narrower: it gives the QA-before-QA checks that theme teams can run on rendered pages.
Worked Example: A Listing Card Before QA
Take a news listing card with image, title, teaser, date, and topic. Before QA, create three test nodes: one with a long title, one without an image, and one with a short teaser. Navigate the listing by keyboard and screen-reader name, then inspect whether each card has a single clear action.
If focus lands on the image, title, and read-more link separately, the QA issue is not a content problem. It is a theme output problem. Fix the template once, document the expected editorial fields, and then retest the listing, related-content block, and homepage view mode.
Run the same check with editor permissions, not only as an administrator. Editorial toolbars, unpublished labels, contextual links, and moderation states can change the page enough to expose focus traps or confusing names. If editors cannot preview the accessibility impact of their choices, the theme team will keep receiving defects that look random but share the same content pattern.
The audit should also include failure states. Empty search results, validation errors, missing media, long taxonomy labels, and unpublished content often receive less design attention than perfect pages. Those states are exactly where accessibility problems become expensive, because they are discovered by users or QA after the main templates have already been accepted.
Make The Check Part Of Theme Delivery
Accessibility work gets expensive when every finding becomes a late exception. Add these checks to theme pull requests, content model demos, and pre-launch editor walkthroughs. The review does not need to be huge; it needs to happen while the Drupal team can still fix patterns at their source.