Why themes fail in predictable places
Themes and templates are built to demo well. They are not built around your journeys, your content, and your edge cases.
Accessibility issues show up first where interaction is complex and where content varies Source 2 .
Where accessibility breaks first
1) Navigation
Navigation often includes submenus, mobile panels, and toggles. This is where keyboard and focus problems appear early Source 1 .
- Keyboard users fail to reach submenus Source 1 .
- Focus gets trapped inside the menu, or escapes behind it Source 1 .
- Focus order becomes confusing when the menu opens Source 1 .
- The open and close controls are not announced clearly Source 1 .
- Touch targets are too small on mobile Source 1 .
2) Modals and overlays
Themes often add pop-ups, search overlays, cookie panels, and lightboxes. These break when focus is not managed properly Source 1 .
- The modal opens but focus stays behind it Source 1 .
- Focus is not trapped in the modal Source 1 .
- The close button is not reachable or not clear Source 1 .
- Closing the modal drops focus into nowhere Source 1 .
- Background content remains scrollable and interactive Source 1 .
3) Forms
Forms are where money and leads happen. They are also where theme shortcuts cause the most harm Source 3 .
- Labels replaced with placeholders Source 3 .
- Required fields not explained Source 4 .
- Validation messages unclear or missing Source 4 .
- Error messages not connected to fields Source 4 .
- Users fail to complete the form with keyboard only Source 1 .
4) Content blocks and page builders
Flexible blocks make it easy to publish broken structure Source 1 .
- Headings used for styling, not structure Source 1 .
- Missing headings, causing long pages with no navigation Source 1 .
- Buttons built from non-button elements Source 1 .
- Link text such as click here, read more, and learn more with no context Source 1 .
- Decorative icons included as meaningful content with no alternative Source 1 .
5) Interactive components
Themes often include carousels, accordions, tabs, and filters. Many are not built with correct keyboard patterns and states Source 1 .
- Carousels that auto-advance with no pause control Source 1 .
- Accordions that do not expose expanded state Source 1 .
- Tabs that do not support expected keyboard navigation Source 1 .
- Filters that update content without announcing changes Source 1 .
Why bespoke builds often perform better
Bespoke does not automatically mean accessible. It usually means you control patterns and enforce consistency Source 2 .
- You define one navigation pattern and test it properly Source 2 .
- You define one modal pattern and reuse it everywhere Source 1 .
- You define one form pattern and keep errors consistent Source 5 .
- You limit third-party UI to reduce unpredictable behaviour.
How to reduce risk if you choose a theme
Audit the theme before content build starts
- Test navigation with keyboard only Source 2 .
- Test any modal or overlay behaviour Source 2 .
- Test contact forms and common input patterns Source 3 .
- Test at 200% zoom and on mobile Source 1 .
Lock the patterns
Accessibility improves when patterns are consistent Source 1 .
- Provide reusable blocks for common content structures.
- Provide a heading and content guide for editors.
- Avoid a page builder free-for-all.
- Reduce plugins and third-party widgets.
What to ask a supplier
- How they test keyboard journeys Source 2 .
- Whether they provide a sample audit report with real findings and fixes.
- Whether they provide retesting after fixes Source 2 .
- How they prevent accessibility regressions when content editors publish pages.
Next step
If you are choosing between a theme and a bespoke build, compare risk and change cost, not launch speed alone. Ask for evidence of testing on navigation, modals, and forms, because those areas fail first Source 2 .
Sources
- [1] W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Back to article
- [2] W3C WAI. Evaluating Web Accessibility Overview. Back to article
- [3] W3C WAI. Forms tutorial. Back to article
- [4] W3C. WCAG 2.2, Guideline 3.3 Input Assistance. Back to article
- [5] GOV.UK Design System. Error message component. Back to article