Accessibility Breakdown

We just finished re-auditing this site for accessibility, which means we spent a week thinking about doorways. That’s the honest way to understand this subject: a website is a building, and accessibility is whether people can actually get in and move around. Not a legal checkbox, not a plugin you install and forget. Doors.

The trouble is that most writing about it sounds like a compliance manual, so here’s the version we’d give a client over coffee. Six things, plain English, with the ten-second check for each.

Contrast

Can you read the text? Not you, at noon, on a $2,000 monitor. A tired person, on a five-year-old phone, outside. Light gray on white and dim gray on black both photograph beautifully and read terribly, and designers fall for it constantly. We did; our own muted gray failed the math and we brightened it last week.

The ten-second check: squint at your site. Whatever disappears first was already too faint.

Keyboard and tab order

Plenty of people never touch a mouse: some can’t, some use screen readers, some are power users who just prefer keys. Press Tab and your site should walk them through everything clickable, in a sensible order, with a visible outline showing where they are. If the highlight vanishes mid-page or jumps somewhere random, a whole group of visitors just got lost in your building.

The ten-second check: put the mouse down and try to reach your contact form using only Tab and Enter. Genuinely try it. It’s humbling.

Skip to content

Related, and wonderfully simple: keyboard users shouldn’t have to Tab through your entire navigation on every single page just to reach the article they came for. A “skip to content” link, hidden until it’s focused, lets them jump straight past the menu. It’s one link. It costs nothing. Its absence costs someone forty keystrokes a page.

ARIA and labels

Screen readers describe your page out loud, and they can only describe what the code tells them. An icon-only button with no label gets announced as, literally, “button.” Button that does what? ARIA attributes and labels are how you whisper the answer: “Copy link.” “Share on Facebook.” “Photo 2 of 5, selected.” The rule of thumb is that anything a sighted person understands by looking at it needs a written equivalent in the code.

The ten-second check: find every button on your page that’s just an icon. Each one needs a name.

Reduced motion

Some people get genuinely dizzy or nauseated by things sliding, zooming, and parallaxing at them. Every phone and computer has a setting where they can ask for less motion, and your site can listen for it with a few lines:

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none;
    transition: none;
  }
}

Sites as animated as ours have real work to do here, because the JavaScript needs the same manners as the CSS. But the principle fits in one sentence: motion should be a preference, never a toll.

Alt text

Every meaningful image needs a short written description, which is what a screen reader speaks and what search engines read. The craft is in the judgment: a client’s logo should say the client’s name; a purely decorative flourish should be marked decorative so it stays silent instead of narrating clutter. Describe what matters, hush what doesn’t.

None of this is exotic, and that’s sort of the point. Accessibility work is mostly small courtesies applied consistently: readable text, reachable buttons, named controls, respected preferences. It overlaps almost perfectly with good SEO and good design, because all three are the same discipline wearing different badges. Build the thing so everyone can use it.

And do the audit even when you think you’re fine. We think about this stuff professionally and still found a gray that failed, a link that was nearly invisible, and a carousel that wouldn’t sit still when asked. The doors were mostly open. Mostly is the word the audit exists to find.