Accessibility usually gets introduced in one of two unhelpful ways.
The first is fear: you might get sued, here is a checklist, install this widget. The second is charity: some people have disabilities, and we should be considerate. One produces box-ticking, the other produces good intentions that never reach the backlog.
Both miss what is actually true, which is simpler and more useful: an inaccessible site is a site that excludes customers, and almost everything you would do to fix it makes the site better for everyone.
That is not a moral argument. It is a design argument that happens to also be the right thing to do.
Who this is actually about
The mental image is a screen reader user who is blind. That person matters and is genuinely affected. But framing accessibility around them alone makes it sound like a narrow case, and it is not.
Consider three overlapping groups:
Permanent. Blindness, low vision, colour blindness — which affects a substantial share of men — deafness, motor impairments, cognitive and learning differences.
Temporary. A broken wrist. Eye surgery. An ear infection. A migraine.
Situational. Reading a phone in bright sunlight. Holding a baby with one arm. Watching a video on a silent train. Using a trackpad on a plane. Being tired at the end of a long day. Being sixty and finding light grey text harder to read than you did at thirty.
The situational group is everybody, sometimes. Which means the design decisions that serve permanent impairments are serving a large portion of your traffic at any given moment, including customers who would never describe themselves as having accessibility needs.
Add the older demographic — often the group with the most disposable income — and the reach argument gets hard to dismiss.
The overlap nobody mentions
Look at what accessible design actually asks for:
- Text you can read without effort
- Clear labels on form fields
- Buttons that say what they do
- Predictable layouts that do not shift or surprise
- Captions on video
- Navigation that works without a mouse
- Meaning conveyed by more than colour alone
Now try to name one item on that list that is bad for a fully sighted, able-bodied user on a fast laptop.
There is not one. Captions serve deaf users and also the majority who watch video with sound off. Good contrast serves low-vision users and also everyone outdoors. Clear button text serves screen reader users and also anyone skimming. Predictable layouts serve users with cognitive differences and also anyone who has ever mis-tapped because the page jumped.
Accessibility and quality are not two projects competing for budget. They are largely the same project.
Where themes fail, and what the fix is
Most accessibility failures on template-based sites are inherited rather than introduced. Here are the ones that show up over and over.
Low contrast text. Light grey body text on white looks refined in a design file viewed on a good monitor in a dim room. It is genuinely difficult outdoors, on a cheap screen, or with ageing eyes. Check your body text, your muted text, your placeholder text, and — most often missed — your accent colour used as text or on buttons.
Removed focus indicators. Browsers draw an outline around whatever is currently selected. Designers frequently remove it because it is not pretty. For anyone navigating by keyboard, this is like removing the mouse cursor. Style it to fit your design; do not delete it.
Placeholder text instead of labels. Grey text inside the field looks tidy, then vanishes the instant someone starts typing, taking the field’s meaning with it. Visible labels above fields, always.
Non-descriptive links. A page with twelve “Read more” links tells someone navigating by link list nothing at all. Make link text describe its destination.
Icon-only buttons with no name. A magnifying glass, a hamburger, a heart. Visually obvious, silent to assistive technology unless a label is provided.
Auto-advancing carousels with no pause control. Content that moves away before it is read, and cannot be stopped, is a barrier for a wide range of users — and it is hard for anyone with a motor impairment to click a target that is sliding.
Custom components built from generic containers. Dropdowns, modals, tabs, and accordions assembled from plain divs with click handlers often cannot be reached or operated by keyboard. Modals are the worst offender: focus stays behind the modal, escape does nothing, and the user is trapped.
Motion with no respect for user preference. Parallax, scroll animation, and heavy transitions can cause genuine nausea and disorientation for people with vestibular disorders. Operating systems let people request reduced motion; themes should honour that request.
Colour as the only signal. An error field marked only by turning red. Stock status shown only as a coloured dot. A chart legend distinguished only by hue. Add text, icons, or patterns alongside the colour.
Text baked into images. Cannot be read aloud, cannot be resized, cannot be translated, and blurs when zoomed.
Touch targets that are too small. Tiny close buttons and cramped menu items are difficult for anyone with reduced dexterity, and annoying for everyone with an average-sized thumb.
Form errors not connected to their fields. A general “there was an error” at the top of a form, with no indication of which field, is a dead end.
Fifteen minutes of testing, no expertise required
You can find most of this yourself today.
- Put your mouse down. Tab through your homepage and your contact page. Can you see where you are at all times? Can you reach and activate everything, including the menu? Can you escape a modal?
- Zoom to 200%. Text should reflow, not overlap or get cut off.
- Read your link text out of context. Copy every link label on a page into a list. Does it still make sense?
- Check your contrast with any online contrast checker — body text, muted text, and text on your accent colour.
- Go outside with your phone. The most honest contrast test there is.
- Turn off images and see whether the page still communicates anything.
- Submit a form incorrectly and see whether the error tells you which field and why.
None of this requires a specialist. All of it finds real problems.
An honest note about automated checkers
Automated accessibility tools are useful and worth running. They are also frequently oversold.
They reliably catch machine-detectable problems: contrast ratios, missing alt attributes, missing form labels, invalid markup. They cannot tell you whether your alt text is meaningful, whether your keyboard order makes sense, whether your custom dropdown actually works, or whether your page is comprehensible. A significant share of real barriers is invisible to them.
So treat a clean automated report as the floor, not the finish line. And be sceptical of overlay widgets that promise instant compliance from a single script — they are widely criticised by disabled users themselves, and they do not fix underlying markup problems.
The legal picture, briefly
We are not lawyers and this is not legal advice, so treat this as a prompt to check rather than an answer.
The direction of travel is clear: accessibility requirements have been expanding, not contracting. The European Accessibility Act brought obligations for many consumer-facing digital services from mid-2025, various national laws impose requirements on public sector and increasingly private sector sites, and in some jurisdictions accessibility litigation against commercial websites is common.
Whether any of that applies to you depends on where you operate, what you sell, and how large you are. Worth finding out from someone qualified — before it is urgent rather than after.
If you are buying a theme
Ask, and check the demo yourself:
- Tab through the demo. Is focus visible throughout?
- Open the mobile menu with a keyboard. Can you close it again?
- Run the demo’s palette through a contrast checker.
- Ask whether the theme honours reduced-motion preferences.
- Ask what accessibility testing was done, and whether any was manual.
A studio that has done this work will answer specifically. A studio that has not will mention a plugin.
If you are building one
Build it in from the start. Retrofitting accessibility means rebuilding components, revisiting the palette, and rewriting markup — expensive work that would have cost almost nothing at design time.
Choose your colours against contrast requirements while choosing them. Design the focus state alongside the hover state. Specify keyboard behaviour for every custom component in the design file. Test with a keyboard before shipping.
The summary
Accessible design is not a constraint on good design. In practice it is a description of it: readable text, clear labels, honest structure, predictable behaviour, and controls that work however someone chooses to operate them.
Sites that do this are easier for everyone to use — and they are available to a meaningfully larger number of customers than sites that do not.
At eThemeStudio, accessibility is part of the build rather than an audit at the end: contrast checked on the actual palette, focus states designed rather than deleted, keyboard paths tested manually, and motion preferences honoured. Want to know how your current theme holds up? Send us the URL and we will run the fifteen-minute test with you.
Comments (0)