Short answer. Accessibility means the site can be used with a keyboard, a screen reader and at increased zoom. An "accessibility widget" — the floating button that changes font size and colours — does not create it: the overlay restyles the same markup, while the cause of inaccessibility is in the markup. The practical minimum is semantics, contrast, keyboard support and labelled fields, and half of it can only be checked by hand.
Who is legally required to be accessible, and who simply benefits
Legal exposure depends on jurisdiction: in the United States it comes through the ADA and Section 508, in the European Union through the European Accessibility Act and EN 301 549, and public-sector sites in most countries have their own rules on top. What all of them have in common is that they reference WCAG at level AA rather than inventing their own criteria. The exact scope and deadlines change — verify them against the current legislation, not a blog post.
For a commercial site with no statutory duty, accessibility still pays off for three reasons, none of them charitable:
- Part of your audience simply cannot buy. Not only blind users: a temporary cast, bright sunlight on a phone screen, a noisy train, age-related long-sightedness — the same barriers as permanent impairments.
- Accessible markup is semantic markup. Ordered headings, labelled fields and meaningful link text serve the screen reader and the search crawler equally.
- Accessibility catches ordinary interface bugs. A form you cannot complete with the keyboard is usually broken with a mouse too — it was just noticed later.
Accessibility overlays: why a button does not make a site accessible
The quickest-looking fix is an overlay widget: a floating icon hiding toggles for font size, colour scheme, letter spacing and image suppression. It looks like a requirement satisfied, but it covers only a small part of the job.
The overlay works on top of the same markup. It can change appearance; it cannot repair the cause. If an image has no description, the screen reader stays silent at any font size. If a button is a div with no role, growing it does not make it a button. If a field is not associated with a label, the reader still cannot say what to type.
The intended user usually does not use it. A blind visitor arrives with their own screen reader; a low-vision visitor with system magnification and their own contrast settings. Those tools are already tuned to that person far better than any on-page panel.
An overlay can actively interfere. Widgets that aggressively rewrite the page and inject their own ARIA can conflict with screen readers and degrade what previously worked. That is precisely why the assistive-technology community treats overlays with scepticism.
An overlay is a supplement, not a substitute. Installing one is defensible when a formal requirement expects such a version to exist. Believing the job is done once the widget is live is the most expensive mistake in this field: the underlying barriers stay exactly where they were, and the sense of a closed task stops anyone from noticing them.
The claim is testable in a minute: switch the widget on and try to walk the homepage using only Tab. If focus disappears, jumps around or gets stuck inside a modal, the widget did not help — because the problem was never font size.
The WCAG principles: POUR
The standard rests on four principles, and any defect you find sorts neatly into one of them.
Perceivable
- Images carry an
altthat describes meaning, not the file name. - Video has captions; important audio has a transcript.
- Colour is not the only carrier of meaning: "fields marked in red" is invisible to a colour-blind user.
- Text contrast is at least 4.5:1, or 3:1 for large text.
Operable
- Every function works from the keyboard, including menus, modals and sliders.
- Focus is visible, and the tab order matches the visual order.
- Nothing flashes more than three times per second.
- Timed interactions can be extended or turned off.
Understandable
- The page language is declared, or a reader will pronounce the text with the wrong phonetics.
- The interface behaves predictably: focusing a field does not navigate on its own.
- Form errors explain what is wrong and how to fix it.
Robust
- Markup is valid and elements are not nested arbitrarily.
- ARIA is used sparingly and never contradicts the native semantics.
The practical minimum that removes most barriers
Full WCAG is large, but the overwhelming majority of real problems on an ordinary site are the seven items below.
1. Semantic markup instead of a pile of blocks
<!-- Bad: a block with a click handler -->
<div class="nav">
<div class="nav__item" data-href="/en">Home</div>
</div>
<!-- Good: a link stays a link, navigation stays navigation -->
<nav aria-label="Main navigation">
<a href="/en">Home</a>
</nav>A clickable div is skipped by keyboard navigation, announces no role to a screen reader and cannot be opened in a new tab with a middle click. A link or a button gets all of that for free.
2. Meaningful image descriptions
<!-- Decorative: empty alt so the reader skips it -->
<img src="divider.png" alt="">
<!-- Informative: describe the meaning, not the appearance -->
<img src="chart.png" alt="Revenue grew 45% in the third quarter">
<!-- Image link: alt describes where the link goes -->
<a href="/en/pricing"><img src="banner.png" alt="Plans and pricing"></a>An empty alt is a tool rather than a mistake: it tells the reader "skip this, it is decoration". The mistake is omitting the attribute, which makes the reader announce the file name.
3. Labelled form fields
<!-- Bad: the label lives in the placeholder and vanishes on input -->
<input type="email" placeholder="Your email">
<!-- Good: an explicit association between label and field -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email"
aria-describedby="email-hint">
<p id="email-hint">We will send your order confirmation here</p>A placeholder is a hint, not a label: it disappears as soon as typing starts, has low contrast and is not announced by every reader. The autocomplete attribute helps far beyond accessibility — it saves everyone time.
4. Contrast
Light grey text on white is the most common finding of any audit. The minimum is 4.5:1 for body text and 3:1 for large text, and it applies to button labels, field hints and text over photographs. Check the :disabled state and placeholders separately: they are often faded to the point of being unreadable.
5. Keyboard support and visible focus
Walk the page with Tab from top to bottom. Everything interactive must receive focus, the order must match the visual layout, and the focus ring must never be removed without a replacement. The rule is simple: outline: none with no visible focus style of your own is a defect, not a design decision.
6. Ordered headings
One h1 per page, then h2 and h3 by nesting, with no level skipped for the sake of font size. Screen readers navigate by headings, and for a blind visitor that is the equivalent of skimming a page by eye.
7. Zoom and touch target size
The page must stay usable at 200% zoom: no horizontal scrolling, no overlapping blocks. Touch targets on mobile should be at least 44 pixels on each side, or they are unreachable both for someone with a tremor and for anyone tapping while walking.
ARIA: first, do not use ARIA
The first rule of ARIA is not to use it when a native element does the job. A real button already announces its role, takes focus and responds to Space and Enter; a div with role="button" has to be re-equipped by hand, and part of the behaviour will still differ.
<!-- Redundant and fragile -->
<div role="button" tabindex="0" aria-pressed="false">Submit</div>
<!-- Sufficient -->
<button type="submit">Submit</button>
<!-- ARIA belongs where no native element exists -->
<div role="status" aria-live="polite">Your request has been sent</div>Wrong ARIA is worse than none: the attribute overrides what the browser was already communicating, and the reader starts describing the element incorrectly. When in doubt, drop the ARIA and use the native tag.
Testing: automation catches less than half
Automated scanners find what can be formalised: a missing alt, insufficient contrast, an unlabelled field, duplicate identifiers. Everything else — whether descriptions make sense, whether focus order is logical, whether errors are understandable — takes a human. So testing has two halves, and the second cannot be skipped.
A perfect automated score is not a passing grade. It only means no formalisable violation was found. Studies of automated tooling consistently put its coverage at a minority of real WCAG failures — the rest live precisely in the judgement calls a scanner cannot make.
The automated half. Built-in browser dev tools can run an accessibility audit, and axe-based extensions give a detailed list of violations with the offending nodes. Do not run it on the homepage alone: typical defects live on product pages, in carts and in forms.
The manual half — four checks, a couple of minutes each:
- Keyboard only. Take your hand off the mouse and walk a key scenario: menu, form, modal, submit. Check that Escape closes the modal and that focus does not escape behind it.
- Screen reader. Every modern operating system ships one. Half a minute on the homepage is enough to hear whether it is clear where you are and what the links say.
- 200% zoom. Magnify the page and look for horizontal scrolling and overlapping content.
- Images off. The fastest way to see where alt text is missing or meaningless.
It helps to capture the page's general state — status codes, headers, speed — before an audit, so that inaccessibility is not confused with an ordinary fault: use the site audit, the header check and the speed test. A slow page hurts everyone, but it hurts assistive-technology users more: the reader announces what has already rendered.
Typical violations and how to fix them
| Violation | Who it breaks | How to fix |
|---|---|---|
Clickable div instead of a button or link | Keyboard, screen reader | Use a native button or a |
outline: none with no replacement | Everyone navigating by Tab | Provide a visible focus style of your own |
| Field label only in the placeholder | Screen readers, cognitive load | An explicit label for |
| Light grey text on white | Low-vision users, anyone in sunlight | Raise contrast to 4.5:1 |
| Headings picked by font size | Screen-reader navigation | Order levels by meaning, set size in CSS |
| Modal with no focus trap and no Escape | Keyboard users | Keep focus inside, close on Escape, return focus afterwards |
| Meaning conveyed by colour alone | Colour-blind users | Add text, an icon or a label |
| Page language not declared | Screen readers | Set the language attribute on the root element |
| Video autoplaying with sound | Almost everyone | Disable autoplay, provide controls |
Accessibility and SEO: where they overlap
The overlap is real but should not be turned into a ranking promise. What genuinely coincides is document structure:
- Ordered headings help a screen reader and a crawler understand structure in the same way.
- Image descriptions serve accessibility and are the only way search can interpret a picture; how to write them is covered in image optimisation.
- Meaningful link text instead of "read more" benefits both.
- Speed and layout stability are part of the experience, and their metrics are covered in the Web Vitals guide.
What accessibility does not do: it will not lift your rankings on its own and it does not replace work on content. Treating it as an SEO tactic is a route to disappointment.
Frequently asked questions
Is installing an accessibility widget enough?
No. The overlay restyles the same markup and does not repair the cause: missing descriptions, elements unreachable by keyboard, unlabelled fields. It can make sense as a supplement, or where such a version is formally expected, but it does not replace the underlying work.
Where do I start on a tight budget?
With the keyboard and contrast. Walk a key scenario with Tab and raise text contrast — the two cheapest fixes with the most visible effect. Field labels and image descriptions come next.
Should I build a separate version for blind users?
No, and it is the worst available option. A separate version almost always falls behind on content and dies first at the next redesign. The main version is the one that has to be accessible.
How do I know whether the mandatory rules apply to us?
It depends on jurisdiction, sector and whether you serve the public, and the wording is worth checking with a lawyer rather than inferred from a neighbouring site. What is stable across regimes is the reference point: WCAG level AA.
The scanner says 100 out of 100. Does that mean we are fine?
No. That score only means no formalisable violation was found. Whether descriptions are meaningful, whether focus order is logical and whether error messages make sense are not assessed by automation — they are checked by hand.
Will accessibility ruin the design?
Not if it is handled during design. It becomes expensive and visible only when bolted onto a finished interface: visible focus, contrast and target sizes then have to be squeezed into an already approved layout.
Accessibility checklist
- A key scenario can be completed with the keyboard alone, with focus always visible.
- Text contrast is at least 4.5:1, including buttons, hints and disabled states.
- Informative images have a meaningful
alt; decorative ones have an empty attribute. - Every form field is associated with a label, not just a placeholder.
- Form errors explain cause and remedy in text, not by colour alone.
- Headings follow their levels and there is one
h1per page. - The page language is declared.
- Modals trap focus, close on Escape and return focus to the trigger.
- At 200% zoom there is no horizontal scrolling and no overlap.
- Touch targets on mobile are at least 44 pixels.
- An automated audit has been run and the four manual checks completed.
- Any accessibility widget in place is treated as a supplement, not as the result.