Development

Website accessibility: who it's for and why

Accessibility isn't only for people with disabilities. Contrast, keyboard navigation, field labels and alt text — and why it's cheaper to build in from the start.

Accessibility is usually filed under "social responsibility": useful, but not about revenue and not about our case. That's an inaccurate frame. Most accessibility requirements describe ordinary situations any visitor finds themselves in, and failing to meet them costs you requests every day.

Who actually needs it

Accessibility is about a website being usable in less-than-ideal conditions. Everyone ends up in less-than-ideal conditions.

  • A person reads their phone screen in bright sunlight. Light grey text on a white background ceases to exist.
  • A person's mouse broke or ran out of battery, and they're moving through the page with the Tab key.
  • A person watches a video in a noisy place without headphones — and without subtitles understands nothing.
  • A person is holding a child in one arm and keeps missing the small buttons.
  • A person is over fifty and reads small print worse than the thirty-year-old designer.
  • A person has a slow connection, the images didn't load — and instead of products they see empty rectangles.
  • A person uses a screen reader because they can't see.

The first six aren't a minority. They're an ordinary day for an ordinary audience. And the solutions that help in these situations are exactly the same ones the last case needs.

Accessibility isn't a separate version of the site for special users. It's the quality of the main version, tested in conditions different from the developer's office.

What it means in practice

Contrast

The most common and cheapest violation. Light grey text on white, white on a light background, a caption over a photo with no backing — all of it readable indoors and gone outdoors.

There's a verifiable criterion: the luminance ratio between text and background. The international accessibility guidelines, WCAG, set minimum values separately for normal and large text. It's not a matter of taste — contrast is measured with a tool, and the result either passes the threshold or it doesn't.

Checks cover not only text but also input field borders, icons and button states. A button that differs on hover only by a barely noticeable shade isn't just inaccessible to people with colour vision deficiency — it simply can't be seen.

And a related rule: colour mustn't be the only carrier of meaning. If an error in a form is marked only by a red border, some people won't see it. There needs to be text as well.

Keyboard navigation

The check takes a minute: open your site and try to get through it using only Tab and Enter. Three things break most often.

  1. You can't see where focus is. A developer removed the "ugly" outline around the active element and didn't replace it with anything. As a result, a person presses Tab and doesn't understand where they've landed.
  2. There are traps. A pop-up opened and can't be closed with the keyboard. Or focus falls into a widget and never comes back.
  3. Things can't be activated. A button is built as an ordinary block with a click handler, and the keyboard can't reach it at all.

A useful detail: a "skip to content" link at the very top of the page, so people don't have to go through the whole menu every time.

Field labels

A label should be permanent and linked to its field. A common mistake is a hint inside the field instead of a label: the person starts typing, the hint disappears, and they no longer remember which field they're in. It's especially painful in long forms and when filling them in on a phone.

Next is format. If a phone number has to be entered in a certain way, that should be written in advance, not pop up as an error after submission. The error itself should say what exactly is wrong and what to do, and sit next to the field rather than in a general line at the top.

Required fields are marked clearly. Better still — don't make required what you can do without: every extra field reduces the number of submitted forms.

Alt text

A text description of an image is needed when the image carries meaning: a product photo, a diagram, a screenshot, a chart. The description should convey the meaning, not the file name or a string of keywords.

Purely decorative images don't need a description — they should be marked as decorative so screen readers skip them. Reading background patterns aloud is worse than silence.

A separate case is text embedded in an image. It can't be enlarged, selected, translated or found by search. A price list or promotion terms as an image is lost information.

Structure and clear text

Headings should be headings, not large bold text. Levels go in order — screen readers, search engines and people scanning the page with their eyes all navigate by them.

Links should be understandable out of context. Ten "read more" links in a row say nothing; "delivery terms" does. The same rule makes life easier for anyone skimming the page.

Why it's cheaper to build in from the start

The difference isn't in the amount of work but in what exactly has to be redone.

At the design stage, choosing a contrasting colour pair costs nothing extra. After launch, it means revising the palette — and with it every mock-up, banner and ad made in the old colours.

At the build stage, using the right elements for buttons and fields also costs nothing; it's simply the correct way. After launch, it means rewriting the interface and retesting every scenario.

Adding labels to a form during design takes a minute. Reworking a form that already has analytics and a CRM integration set up is a separate task with regression testing.

Add to this that some accessibility solutions directly improve other metrics: correct heading structure helps search, clear labels and error messages increase the share of completed forms, avoiding text in images makes content indexable. It's not charity but normal quality of execution — we treat it as part of our work on websites.

There are also direct requirements: organisations in some industries and anyone working with government clients are obliged to comply with accessibility standards. For such projects the question isn't "is it needed" but "how to demonstrate it".

What to check today

  1. Go through the site with Tab: is focus visible, are all buttons reachable, can you get out of pop-ups?
  2. Open the home page on a phone outdoors on a sunny day.
  3. Run the main colours through any contrast calculator and check them against the WCAG thresholds.
  4. Check whether form fields have permanent labels and clear error messages.
  5. Find the images that carry meaning and make sure they have descriptions.
  6. Check whether any important information exists only as an image.
  7. See whether headings go in level order and haven't been replaced by large bold text.
  8. Zoom the page in the browser and make sure the layout doesn't fall apart.

The first four points cover most real problems. If during the check you find something you're not sure how to fix, write to us — we'll look at the specific case.