blog single

Website accessibility: a practical start for small teams

Colleagues reviewing a website at a desk

Published on:

February 15, 2024

TAG:

UI/UX DESIGN

BY:

Edgeless Team

Read Time:

6 MIN READ

post detail

Accessibility work has a reputation for being large, technical and separate from design. In practice, most of the barriers on a typical business website come from a short list of decisions: small text, low contrast, missing labels, keyboard traps and content that only makes sense when you can see it. A small team can fix most of that list without rebuilding the site.

Accessibility is a design constraint

The Web Content Accessibility Guidelines, currently version 2.2, describe four principles: content should be perceivable, operable, understandable and compatible with different browsers and assistive technology. Those principles are a useful design brief. Can a person who cannot see the screen understand the page? Can a person who cannot use a mouse reach every control? Can a person with a cognitive disability follow the flow without fighting it?

Teams often treat accessibility as a checklist applied at the end. That is the most expensive time to apply it because the structure is already fixed. It is cheaper to choose semantic elements, readable contrast and clear labels while the design is still a wireframe.

Legal requirements vary by country and sector. In many places, public sector sites and some private services are expected to meet level AA. Even where the law is unclear, the practical case is strong: accessible sites work better on small screens, in bright light, with slow connections and for people who are tired or distracted. That group is larger than any single accessibility category.

The fixes with the highest impact

Start with the text. Body copy below 16 pixels is hard to read for many people, and low contrast makes it worse. Aim for a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text. Check the actual colors, not the intended ones, because a brand color often fails when used for small labels.

Next, make every interactive element reachable and visible. Links, buttons, form fields and menu items should work with the Tab key, and the focus state should be obvious. Remove CSS that hides focus outlines. If the design needs a custom focus style, make it at least as visible as the browser default.

Use real buttons for actions and real links for navigation.
Give every image an alt text that describes its purpose, or an empty alt if it is decorative.
Label every form field and keep the label visible after the field is filled.
Do not use color alone to communicate status or required fields.
Provide captions and transcripts for video and audio content.
Keep touch targets large enough to tap without precision.
Respect reduced motion settings for animations and auto-playing carousels.

Forms are where most sites fail

Forms combine several risks at once: labels, errors, focus order, time limits and instructions. A field that looks labelled because of placeholder text is not labelled once the user starts typing. An error message that appears in red without text is invisible to a screen reader. A required field marked only with an asterisk is ambiguous.

Use a visible label above each field, a hint where the format matters and an error message next to the field that says what went wrong and how to fix it. Announce errors to assistive technology, and never clear the form when validation fails. On mobile, set the correct input type so the keyboard matches the field.

Test the form with the keyboard only. Tab through it, submit it with an error, fix the error and submit again. If you cannot complete the flow without a mouse, neither can a large group of your customers.

Two people reviewing a form flow on a laptop — Test forms with the keyboard and a screen reader. Most accessibility failures show up in the first two minutes.

A testing routine a small team can keep

You do not need a formal audit every sprint. A short routine catches most regressions. Once per release, tab through the main templates. Run an automated checker such as axe or Lighthouse and read the issues, not just the score. Try the site at 200 percent zoom. Turn on a screen reader for the primary flow and listen for missing labels and confusing order.

Automated tools find missing alt text, low contrast and some structural problems. They cannot tell you whether the alt text is useful or whether the flow makes sense. That part needs a person, ideally someone who uses assistive technology. If you do not have that person on the team, hire a tester for a short review or work with a local accessibility group.

Keep a short checklist in the pull request template. Five or six items are enough: semantic headings, labels, focus states, alt text, contrast and keyboard access. The checklist is a reminder at the moment when the decision is cheap to change.

Content decisions matter as much as code

Plain language helps everyone. Short sentences, one idea per paragraph, descriptive link text and headings that describe the section. Avoid link text such as 'click here' because screen reader users often navigate by links alone and a list of identical labels is useless.

Write alt text for purpose, not for search ranking. A product photo should say what the product is. A decorative shape should have an empty alt so it is skipped. A chart needs a short description and a data table if the numbers matter. If an image contains text, put the text in the page as well.

Documents deserve a plan. A brochure or price list published only as a PDF is difficult to read on a phone and often impossible for a screen reader. Publish the key information as HTML and keep the PDF as a download for people who want to print it. When a document must be a download, give it a descriptive name and state the format and size in the link text.

Build the rules into the design system

If your site uses a component library, put accessibility into the components rather than into each page. A button component should carry a visible focus state, a disabled style that still reads as disabled and a minimum touch target. A form component should render its own label, hint and error region. A modal should trap focus, close on Escape and return focus to the control that opened it.

Document the rules next to the components. When the guidance lives in a design file with annotations, new pages inherit it. When it lives in a wiki nobody opens, each new page reinvents the same three bugs. The design system is also the cheapest place to fix contrast, because one token change updates every surface that uses it.

Motion needs a rule too. Carousels that advance on their own, parallax backgrounds and looping video can cause discomfort for people with vestibular disorders. Respect the reduced motion media query, offer controls to pause anything that moves, and avoid autoplay with sound. These changes rarely affect the visual design and cost little to implement.

If a person cannot complete the main task with a keyboard and a screen reader, the page is not finished. The checklist finds the gap. Closing it takes design and build work.
Edgeless Team

How to start next week

Pick the three pages that carry the most traffic or revenue. Run them through the keyboard, zoom and screen reader checks. Fix the issues you find before adding new ones. Then add the checks to the release routine so the fixes stay fixed.

Assign an owner. Accessibility work stalls when it belongs to everyone and nobody. The owner does not need to be an expert. They need the authority to block a release when a core flow fails and the time to keep the checklist current.

We can review your main templates, test the core flows and give your team a prioritized list of fixes that fit the current design.

Explore UI and UX design

Accessibility is a set of habits that keep the site usable as content, components and teams change. Start with the highest traffic pages and keep the routine small enough to survive a busy month.

Accessibility

UX Design

WCAG

Website accessibility: a practical start for small teams

Let's Talk About Your Project