Isn't accessibility just about screen readers?

No. It covers keyboard users, people with low vision or color-vision deficiency, people who need captions, and anyone in a temporary bind such as bright sunlight or a broken arm. Accessibility often improves usability for many other visitors too.

Is accessibility a legal requirement?

In some cases, yes. In the EU, the European Accessibility Act covers specified services — including online services aimed at concluding consumer contracts — not every website, and a legally defined microenterprise providing services is exempt under the Directive, though national law can reach further. Treat WCAG 2.2 AA as the technical target and check the law that applies to you; conformance alone doesn't settle the legal question.

Can an automated tool tell me if my site is accessible?

Only partly. Checkers can flag some missing accessible names, markup errors and straightforward contrast failures — but they can't judge whether labels are meaningful, interactions work, or the reading experience makes sense, and they produce false positives too. Combine automated checks with informed keyboard and screen-reader testing, and where practical, testing by disabled users.

Can disabled visitors actually use your site?

Accessibility means building your site so that people with disabilities — visual, motor, hearing, or cognitive — can actually use it. It is its own discipline; clean, semantic HTML is a foundation but does not cover everything. The encouraging part: the basics are practical, and they often make the site easier for many other visitors as well. In the EU, the European Accessibility Act covers specified services — including online services aimed at concluding consumer contracts — with a Directive-level exemption for legally defined microenterprises providing services; national law can reach further, so treat WCAG 2.2 AA as the technical baseline and check what applies to you.

Make it work without a mouse

Many people navigate entirely by keyboard — and screen-reader users need sound keyboard behavior for controls too, though their reading and navigation work differently and deserve their own test.

All active controls and functionality must be operable by keyboard, with no keyboard trap (disabled controls rightly skip focus; dragging needs a keyboard alternative).
Keep a clear visible focus indicator — suppress the browser default only if you replace it with an equally obvious style.
Keep the DOM reading order logical, with visual and focus order consistent wherever sequence carries meaning — and don't patch bad source order with positive tabindex.

Unplug your mouse and complete a key task. If you can't finish it by keyboard, treat that as a likely barrier and investigate.

Provide real alternatives and measured contrast

Alt text serves the image's purpose in context: convey an informative image's information, name a functional image's action or destination, give complex charts a fuller text equivalent — and use empty alt="" for decoration or images that just repeat nearby text.
Contrast is measurable, not a feeling: WCAG AA means at least 4.5:1 for normal text, 3:1 for large-scale text — and about 3:1 for essential control boundaries, states, focus indicators and meaningful graphics against adjacent colors.
Never rely on color alone. For form errors specifically: identify the field and describe the problem in text; color and icons reinforce, they don't replace.

Label forms, caption media, survive zoom

Every form field needs a properly connected label, with error messages programmatically tied to the fields they describe. For media: synchronized captions for video with audio, transcripts for prerecorded audio-only content, and audio description where a video's important visuals aren't conveyed by its soundtrack — these serve different needs and don't substitute for each other. And check resilience: text enlarged to 200% must lose nothing, and the page should reflow at a 320-CSS-pixel-wide viewport without overlap, clipping or horizontal scrolling (genuinely two-dimensional content like maps and data tables excepted).

Test it three ways — across the real journeys

Keyboard only — through the key tasks, not just one page.
A screen reader — used with basic proficiency (linear listening misses structure problems), on representative templates: navigation, forms and their validation, menus, dialogs.
An automated checker — a first pass for mechanical issues, never a verdict.

Cover the templates, states and journeys that matter — and where practical, testing by disabled users reveals what technical checks miss.

What to do

Confirm the key tasks work by keyboard alone, with visible focus and no traps.
Write purpose-fit alt text — informative, functional, complex and decorative images each get their kind.
Measure contrast against the AA thresholds and never use color as the only signal.
Give every form field a connected label and text-described, programmatically linked errors.
Add captions to video, transcripts to audio-only media, and audio description where visuals carry unspoken information.
Test keyboard + screen reader + automated checker across representative journeys — as a starting point that removes common barriers, not proof of conformance or legal compliance.