The developer "tricks" that quietly break your website
In our What WCAG actually is piece we said accessibility isn't a checklist you finish, it's a way of thinking. It rests on four principles: content that's Perceivable, Operable, Understandable and Robust.
This is the companion piece, because the best way to understand those four principles is to watch them being broken.
Every "trick" (read: error) described beneath is a shortcut a well-meaning developer reaches for, because it's quicker, easier or looks tidier in the design. It's not malice, it just comes from not realising how one quarter of the UK population actually live. And every one secretly locks somebody out.
Each trick has two parts: the shortcut we devs typically go for and the more-accessible "proper" solution to the problem they were trying to fix. If you ARE the developer, take a look and see if you recognize any of these in your own work. If you're not, have a read and ask whoever maintains your site the questions we've suggested.
1. The home-made pop-up box
Breaks: Robust
The browser has a built-in pop-up. Give it the word "modal" and it does a surprising amount for free: it moves the keyboard's focus into the box, holds it there so you can't accidentally tab out into the page behind, closes on the Escape key, and greys out everything underneath so assistive tech knows the rest of the page is off-limits for now.
A hand-built pop-up, a plain box that's been positioned to float in the middle of the screen, does none of that unless someone remembers to add it back, and they almost never remember all of it. The usual result is a keyboard user who tabs "into" the pop-up, falls straight through it into the hidden page behind, and gets lost with no way back.
Ask whoever builds your site: do our pop-ups use the browser's built-in dialog, or a custom one?
For the developer: reach for <dialog> and open it with showModal(). Focus handling, the Escape key and the inert background are handled for you, and you can style the dimmed background with ::backdrop. The rule of thumb for this whole article: if the browser already does something, let it.
2. The fake button
Breaks: Robust
A button doesn't have to be a real button to look like one. You can take any box on the page, paint it blue, round the corners, and wire it up so that clicking it does something. To a sighted mouse user it's indistinguishable from the real thing.
To everyone else it's a trap. Behind the scenes, the browser builds a hidden map of the page for assistive tech, listing what each thing is and what it's called. A real button goes onto that map announced as a button, with a name, reachable by keyboard. A painted box goes on as nothing in particular: the keyboard can't land on it, and a screen reader skips straight past it. The thing that looks the most clickable on the page is invisible to the people who need it labelled most.
Ask whoever builds your site: are our buttons and links the real thing, or lookalikes?
For the developer: use <button> for an action and <a> for a destination. If you've inherited a <div> with a click handler, replacing it is usually a five-minute job and it hands you keyboard support and the correct announcement for nothing.
3. Rubbing out the "you are here" ring
Breaks: Operable
Tab through almost any website with your keyboard and you'll see a ring, or a glow, move from link to link. That outline is the keyboard user's cursor. It is the only way they can tell where they are on the page.
Designers often dislike the default ring, think it looks like a smudge, and ask for it to be switched off. One line of styling makes it vanish. The site still works perfectly for the mouse user who requested the change, and becomes completely unnavigable for anyone using a keyboard, because they can no longer see where they are. They're tabbing in the dark.
Ask whoever builds your site: if I put my mouse away and press Tab, can I always see where I am on the page?
For the developer: never ship outline: none on its own. If the default ring clashes with the design, restyle it rather than removing it, and scope it to :focus-visible so it shows for keyboard users without appearing on every mouse click.
4. Text you're not allowed to enlarge
Breaks: Perceivable
Your reader has already made a decision about their own eyesight. Somewhere in their phone's settings there's a text-size slider, and if their vision isn't what it was, they've nudged it up (I personally have it set to comically-large proportions nowadays). A well-built site honours that choice and grows to match. Some sites innstead overrule it and stay stubbornly tiny.
Note what the rule actually is here, because it's easy to get wrong. There's no WCAG rule that says "text must be xyz size". The requirement is that the reader stays in control: text has to survive being enlarged to twice its size without breaking, overlapping, or getting cut off. The sin isn't "small text", it's "text the user can't make bigger".
Ask whoever builds your site: if I set my phone to large text, does our site grow with it, or ignore me?
For the developer: sizing type in fixed pixels is what overrides the user's preference. Size it in rem so it scales from the reader's root setting, and check that the layout reflows cleanly at 200% rather than clipping or overlapping. Test it by actually turning your own device's text size up.
5. The disappearing form label
Breaks: Understandable
Forms are where this one lives. Instead of a proper label sitting above each field, the developer puts the hint inside the empty box: that grey "Enter your email" text you see before you start typing. It looks clean. It saves vertical space. And it has three separate problems.
The moment you start typing, the hint disappears, so anyone who gets distracted or comes back to a half-filled form has no way to remember what the box was for. That grey-on-white text is usually too faint to meet contrast requirements. And screen readers don't treat that grey hint reliably as the field's name, so a blind user can land on a box with no idea what it wants.
Ask whoever builds your site: do our form fields have proper labels that stay put, or just grey hint text that vanishes when you type?
For the developer: every field needs a real <label>, tied to its input with for. Keep the placeholder if you like as a genuine example of the format, but it's a supplement to the label, never a replacement for it.
6. The mystery icon button
Breaks: Perceivable and Robust
Icons are lovely and space-saving: a hamburger for the menu, a magnifying glass for search, an X to close. A sighted user has learned to read them at a glance. But an icon on its own carries no text, and text is what a screen reader reads out.
Land on a row of bare icons with a screen reader and you'll hear "button, button, button", with no clue what any of them do. The tidiest, most modern-looking navigation on the site becomes a set of unlabelled doors.
Ask whoever builds your site: do our icon-only buttons have a hidden text label for screen readers?
For the developer: give each one an accessible name, either an aria-label on the button or visually-hidden text inside it. The icon stays exactly as designed; you're just adding the word the screen reader needs.
The thread running through all six
Look back and the same idea sits under every one of these. Assistive technology doesn't see your design; it reads that hidden map of the page the browser builds from your HTML. Use the real elements, <button>, <label>, <dialog>, and the browser fills that map in for you correctly, for free. Fake them with styled boxes and the map comes out blank.
That's the whole of the Robust principle in one sentence: let the browser do the work it already knows how to do.
If you'd like us to check your site for these and the rest, we offer a free WCAG 2.2 AA audit to community organisations. Tell us about your site and we'll be in touch.