Web accessibility basics every team should ship

Accessibility gets treated as a specialist compliance topic, which scares teams into doing nothing. The truth is that a handful of fundamentals cover the vast majority of real-world needs, they're cheap to build in from the start, and they make the product better for everyone — not just users with disabilities. Here's the baseline every team should ship, in priority order.

Start with semantic HTML

The single highest-leverage accessibility decision is using the right HTML element for the job. A <button>\ is focusable, keyboard-operable, and announced correctly by screen readers for free. A <div>\ with a click handler is none of those things.

• Use <button>\ for actions, <a>\ for navigation — never a styled <div>\
• Use headings (<h1>\–<h6>\) in order to convey structure
• Use <nav>\, <main>\, <header>\, and <footer>\ landmarks
• Use real <label>\ elements tied to their inputs

Get this right and you've solved most accessibility problems before writing a line of ARIA.

Make everything keyboard-operable

Many users navigate entirely by keyboard. Tab through your whole app and check two things: can you reach and activate every interactive element, and can you always see where focus is? A visible focus ring is not optional — never remove the outline without replacing it with something clearer.

Watch for keyboard traps (focus that gets stuck in a modal), custom dropdowns that ignore arrow keys, and click handlers on non-focusable elements.

Get contrast and text right

Low-contrast text is the most common accessibility failure and it's trivial to fix. Aim for a contrast ratio of at least 4.5:1 for body text and 3:1 for large text. Don't rely on color alone to convey meaning — an error state needs an icon or text, not just red.

Let users zoom and resize text without breaking the layout, and never disable pinch-to-zoom on mobile.

Handle images and dynamic content

• Give informative images meaningful alt\ text; give decorative images empty alt=""\ so screen readers skip them
• Announce dynamic updates (toasts, live validation) with an aria-live\ region so screen reader users hear them
• Ensure modals trap and return focus correctly

Use ARIA sparingly and correctly

ARIA lets you patch accessibility onto custom widgets, but the first rule of ARIA is: don't use it if native HTML can do the job. Bad ARIA is worse than none — a wrong role\ actively misleads assistive technology. Reserve it for genuinely custom components (tabs, comboboxes, custom dialogs) and follow the established patterns rather than improvising.

Bake it into the workflow

Accessibility fails when it's a pre-launch audit instead of a habit. Cheap ways to keep it healthy:

1. Run an automated linter (axe, eslint-plugin-jsx-a11y) in CI to catch obvious regressions
2. Tab through new features before merging
3. Test occasionally with an actual screen reader (VoiceOver, NVDA)

Automated tools catch maybe half of issues, so the manual checks matter. But this baseline — semantic HTML, keyboard access, contrast, and honest ARIA — clears most of the bar and rarely costs extra time when built in from day one.

If you need an existing product audited against WCAG or want accessibility built into a new build from the start, let's talk.

---

Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.