Accessibility: the minimum worth doing now
Contrast, visible focus, field labels and keyboard support: a baseline level of accessibility in a couple of days, and why it helps every user.
Accessibility often gets postponed as a feature “for a specific audience” the product hasn’t grown into yet. But the baseline isn’t about a specific audience. It’s contrast you can read in sunlight, focus you can see, labels on fields, and an interface you can use without a mouse. Everyone benefits.
Here’s the minimum, none of which requires rebuilding the product.
Contrast
Light gray text on white looks elegant on a good monitor and is unreadable on a phone in the sun or on a cheap laptop. The WCAG guideline is a contrast ratio of at least 4.5:1 for body text and at least 3:1 for large text and meaningful icons.
Where it usually fails:
- muted text: captions, hints, dates;
- placeholders used instead of labels;
- text on colored buttons and over images;
- disabled elements that look exactly like ones that are just pale.
Browser dev tools show the contrast ratio right in the color picker for an element.
Visible focus
Someone moving through the interface with Tab needs to see where they are. The popular fix for “that ugly outline”, outline: none with nothing in its place, makes the interface impossible to use with a keyboard.
Don’t remove the outline. Make it yours: visible, in the product’s colors, shown during keyboard navigation and out of the way on mouse clicks. That’s what :focus-visible is for.
Labels on fields
Every field needs a label that’s tied to it in the markup, not just some text nearby. A placeholder isn’t a label: it vanishes when you start typing, and a second later you can’t remember what the field was.
Same with icon buttons. A button showing only an X or a trash can, with no text label, is announced by a screen reader as just “button”. It needs a name, either visible or via aria-label.
Form errors should be linked to their field and shown with more than color. Some people can’t tell red from green, and to them an error marked only in red is invisible.
Keyboard
Walk through your key flows without a mouse: Tab, Shift+Tab, Enter, Space, Escape, arrow keys. Check that:
- focus reaches every interactive element;
- it moves in a sensible order;
- menus and modals open and close from the keyboard;
- focus doesn’t escape behind an open modal, and returns to where it was after closing.
A common culprit is a div with a click handler standing in for a button. It looks like a button, but you can’t Tab to it or press it with the keyboard. A real button gives you all of that for free.
Motion and text size
If the interface is heavy on animation, respect the system’s reduced motion setting, prefers-reduced-motion. For some people, parallax and sharp transitions aren’t an annoyance, they cause dizziness.
Check that the layout holds up at 200% browser zoom: no clipped text, no buttons piling on top of each other.
Why it helps everyone
High contrast helps in sunlight. Visible focus and keyboard support help power users who’d rather not reach for the mouse. Field labels help anyone who got distracted halfway through a form. Proper markup helps autofill, automated tests and search engines. And in some countries and industries, accessibility is already a legal requirement or a condition of large customers.
Where to start
You don’t need a full standards audit. Take your three main flows and walk them with the keyboard, then check text contrast on the main screens, then labels on fields and icon buttons. That’s a day or two of work, and most fixes land in shared components, so they only have to be made once.
SUBXCAT builds this baseline into a product’s components so that new screens get it automatically.