Search topics
Accessibility settings that need the feature they turn on
No standard requires a high contrast mode or a pause switch, but a site that offers one must let people turn it on without it, not with a switch in faint grey type or placed after the motion it stops.
.tools button { font-size: 12px; color: #767676; } The problem
People who need a setting can't reach the switch that turns it on, because the switch depends on what the setting provides: here, faint type for a contrast mode, and a place after the motion for a pause.
Some sites offer settings of their own: a high contrast mode, larger text, a pause for animations, captions, an easy-read version. Each is there for people who can't use the site as it is, so the switch that turns a setting on is used by exactly those people, before the setting is on, in the look and layout it is there to change. A switch that needs what its setting provides can't be used by anyone who needs the setting.
Riverside Library, a small public library, offers two settings on its quiet, modern site: a high contrast mode, with white text on black and yellow links, for readers who find its grey text hard to read, and a switch that pauses its animations, for readers who can't read while its banner of this week's events changes every few seconds.
The high contrast switch sits in the header, after the menu, set like the rest of the header's small print: 12 pixels, in #767676 grey, with no border. A reader with low vision opens the site to check the opening hours. The large heading is readable. The switch at the far end of the header, the one thing that would make the rest of the page readable for them, is a faint smudge, and with a screen magnifier showing only the top left of the page, it is off screen altogether.
The pause switch is easy to read, so its problem is a different one. It sits in the footer, after the events banner and the rest of the page. A reader who can't take in text while something moves beside it has to read past the banner, or press Tab through every link in it, to reach the one switch that stops it.
First, what the standard doesn't ask: EN 301 549 doesn't require a website to offer a high contrast mode, a text size control, a pause switch or any other setting. A site's own design has to meet WCAG 2.1 A and AA through clause 9 of EN 301 549 whether it has settings or not, so the standard look must already have enough contrast and enlarge without breaking. The settings come on top of that.
What it does ask comes in clause 5.2: where a product has documented accessibility features, it must be possible to turn on the ones a need calls for "without relying on a method that does not support that need". The test is the same for every setting: ask what the setting provides, then check that its switch doesn't need it. A captions switch must not need hearing, a screen reader mode must not need sight, and a keyboard mode must not need a mouse. The library's two switches fail the test in two ways. The high contrast mode is for people who can't read the standard look, and its switch is drawn in the standard look's faintest type. The pause switch is for people who can't cope with the motion, and it can only be reached after it.
The clause applies to web content that has documented accessibility features, which a site has once it describes a setting in its accessibility statement or help pages, the places EN 301 549 12.1.1 names for that information. It isn't in WCAG, so a site can meet every WCAG criterion here and still fail it. The footer switch, for instance, is a way to pause the banner, which is what WCAG 2.2.2 asks for, and the Understanding page for 2.2.2 says nothing about where that way must be.
The failure reaches whoever a setting is for, and every group has settings made for it, so the same mistake can shut out anyone. The library's two switches shut out people with low vision and people whom motion stops from reading, including many people with attention difficulties; the notes show how other settings, placed the same way, reach everyone else. Motion can also make people with vestibular disorders dizzy or sick, and for them, reaching a switch after the motion means sitting through the thing they need to avoid.
10 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (affected)
- No hearing (affected)
- Hard of hearing (affected)
- No speech (affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (affected)
- Seizures (affected)
- Limited vision A reader who needs strong contrast or large text sees the header's small grey line as a smudge, or misses it while a magnifier shows only the top left of the page, so the mode that would help never gets turned on.
- Limited language, cognitive and learning abilities Someone who can't read while something moves beside the text has to get past the rotating banner, and the whole page, to reach the switch that stops it; an easy-read version announced only in a long, dense paragraph is missed the same way.
- Without vision A screen reader mode offered behind an icon with no name, as some overlay launchers are, can only be found by someone who can see the icon.
- Limited manipulation A keyboard mode that opens from a menu shown only on hover, or a switch at the end of a long Tab order, is out of reach of the keyboard user it was made for.
- Limited reach and strength A setting that makes buttons larger, switched on by a tiny icon, is the one control someone with a tremor can't hit.
- Without hearing When the way to turn captions on is explained only in a video's spoken introduction, a deaf viewer misses the one instruction they needed.
- Limited hearing A setting that makes speech clearer, announced only by a spoken message at the start of a video, is missed by someone who can't make out speech.
- Without perception of colour A colour-blind palette chosen from a row of coloured dots, told apart only by their colour, can't be picked by someone who can't tell those colours apart.
- Photosensitive seizures A switch that turns off flashing effects, placed after the flashing banner, can only be reached by looking at the flashes first.
- Without speech A written chat offered only to people who first ask for it by voice, as some phone menus do, can't be reached by someone who can't speak.
Checkers hold a settings switch to the page's own standard, never to what its setting is for. The high contrast switch's grey is 4.54:1 on white, which meets the 4.5:1 that WCAG 1.4.3 asks of text, so axe and every other contrast checker pass it at AA. The pause switch is named, readable and reachable with Tab, so it passes too. No checker knows that these buttons are the way into settings. This audit sends a review lead when a page has a control named for an accessibility setting, such as High contrast, Pause animations, Text size or 文字サイズ, so a person checks it with the need in mind. It can't tell whether someone with that need would reach the control.
AI tools asked to "add a high contrast toggle" or "add a way to pause animations" may put one in the header styled like the links around it, or in the footer with the site's other links, as many sites do. They have no way to ask who the switch is for.
Try it
Imagine this site is hard for you to use until a setting is on. Find the switch that turns it on.
- Broken 1: you need strong contrast to read. Turn on Low-vision view for a rough idea of blurred sight, and look for High contrast.
- Broken 2: you can’t read while something moves. Stop the events banner, by eye or with Tab.
- Apply the fix: both switches come first. With Fix 2, try the device settings under the site too.
Broken Can you fix this?
The fix
Put each accessibility setting where the people who need it can reach it without it, and turn it on from the device's own setting where one exists.
- 1Ask what each setting is for, and make sure its switch doesn't need it.
- 2Put it where people start: before what it changes, early in the header and in the Tab order.
- 3Name it in words, show whether it is on, and follow the device's matching setting where there is one.
A switch drawn in the look it replaces
<header> <a href="/" class="logo">Riverside Library</a> <nav>…</nav> <div class="tools"> <button type="button" id="contrast" aria-pressed="false">High contrast</button> </div></header>Settings first, usable before they are on
<header> <div class="tools"> <button type="button" id="contrast" aria-pressed="false">High contrast</button> <button type="button" id="motion" aria-pressed="false">Pause animations</button> </div> <a href="/" class="logo">Riverside Library</a> <nav>…</nav></header><main> <div class="events">…</div> …</main>The high contrast switch is the faintest, smallest text in the header and the last thing in it, so finding it takes the eyesight the mode is there to replace.
Each switch can now be used by someone who needs its setting, before the setting is on. Both are the first thing in the header, where a magnifier starts and where Tab arrives first, and before the banner, so the motion can be stopped before it has to be watched. They are drawn the way the high contrast mode draws text: 18 pixels and bold, black on white at 21:1 inside a black border, and yellow on black once the mode is on.
Use the first: switches drawn at the high contrast mode's own contrast and size, at the start of the header and before the banner, work for everyone who comes to the site, whatever their device is set to. The second is worth adding to it, because a reader who has already told their device what they need shouldn't have to tell every site again, but on its own it leaves out everyone who hasn't, so it is not enough.
The same rule holds for every setting a site offers: the way to turn it on must not depend on the thing it fixes. Some other common cases.
- A text size control set in small type is the same mistake as the library's high contrast switch. Draw it at least at body size, and set the site's text in rem so the browser's own text size setting works too, with boxes that grow with the text, as enlarged text cut off by fixed-height boxes explains.
- A "Captions" or "Sign language" option explained only in a video's narration is lost on the people it is for. Put the option on the player's bar, as a button with a visible label.
- An easy-read version or a "Listen" button announced only in a long paragraph is missed by the readers who need it. Give it a short, plain label and an icon, at the top of the page.
Keep each control looking the same whether its setting is on or off, apart from its colours, so people can find it again to turn the setting off. Mark its state with aria-pressed, and keep its name the same: "High contrast" pressed or not pressed, never a label that changes to "Standard contrast". Remember the choice with a cookie or local storage, so it holds on the next page.
The banner should also stay still for people whose device asks for less motion even without the switch, as animations that ignore the reduced-motion setting explains, and a pause that only covers one banner doesn't help with motion elsewhere on the page: make the switch stop every animation the site runs.
Windows contrast themes work differently: whatever the site's own mode does, they replace the site's colours with the user's own through forced colors, which the site should allow for, as high contrast mode hiding focus, icons and selections explains. A site's own high contrast mode is for everyone else, which is why its switch has to be easy to see.
A floating accessibility overlay with its own panel of settings doesn't fix this, and can repeat it: the launcher is a small icon, and its panel's switches are set in small type. The settings that matter most, contrast, text size and motion, are better built into the site's own design, where they can be tested.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Verify the fix
4 checks, no mouse.
Test with: Zoom, Contrast measurement, Reduced motion, Keyboard
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after any redesign of the header, the settings or the animations.
Limits
This guide covers a site's own accessibility settings and the way to turn them on. It doesn't cover the contrast of the site's standard look, which WCAG 1.4.3 covers in low-contrast text on brand colours, photos and hover states, the pause that WCAG 2.2.2 asks for in tickers, carousels and animations that can't be paused, or how the high contrast mode itself must keep focus, icons and selections visible. EN 301 549 5.2 applies only to features a product documents, so a site with no settings has nothing to fail here, but that is no reason to drop a setting that some readers rely on. Test with the people each setting is for, with their own devices and settings.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- etsi.org: en_301549v030201p.pdf (opens in a new tab)
- WCAG Understanding: contrast-enhanced (opens in a new tab)
- WCAG Understanding: pause-stop-hide (opens in a new tab)
- developer.mozilla.org: prefers-contrast (opens in a new tab)
- developer.mozilla.org: prefers-reduced-motion (opens in a new tab)
- developer.mozilla.org: aria-pressed (opens in a new tab)
- w3.org: user-stories (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.