Website accessibility (WCAG): the basics for business

Website accessibility means people with different needs can use a site: people with low vision, colour blindness, hearing or motor impairments, as well as older users and anyone using the site in difficult conditions. The international reference point is the WCAG standard (Web Content Accessibility Guidelines). For a business, a basic level of accessibility means sufficient text contrast, image descriptions, keyboard operation, clear forms, video captions and a logical heading structure.

Let us look at why accessibility pays off for business, what the standard requires and which steps to start with without rebuilding the whole site.

Why accessibility concerns every business

Accessibility is often seen as a niche task for specialised or government websites. In reality it affects far more people than it seems.

• Older customers. With age, eyesight and precision of movement decline. Small light-grey text and tiny buttons shut out a significant part of an audience with purchasing power.
• Temporary limitations. A broken arm, tired eyes, a smartphone in bright sunlight, a noisy place without headphones — anyone can end up in such a situation.
• People with disabilities. Screen reader users and people with hearing and motor impairments are full-fledged customers who choose companies that are convenient for them.
• SEO. Many accessibility requirements coincide with what search engines value: heading structure, alt text, descriptive links, clean HTML.
• Exports and international partners. In a number of countries, accessibility requirements for digital services are set in law, and large clients increasingly check this with their suppliers.
• Reputation. A company that thinks about all its customers inspires more trust.

Accessibility is especially important for government websites — more on this in our article on government website design.

What WCAG is and the conformance levels

WCAG is a set of international guidelines on web content accessibility developed by the W3C consortium. The current version is WCAG 2.2. The guidelines rest on four principles: content must be perceivable, the interface operable, information understandable, and code robust — that is, working correctly with different browsers and assistive technologies.

The requirements are divided into three levels:

• A — the minimum, without which some people cannot use the site at all.
• AA — the recommended level that companies and public bodies in many countries usually aim for.
• AAA — the maximum, applied selectively for specific sections or specialised services.

It is important to understand that WCAG is not a box-ticking checklist but a description of real barriers. Each requirement answers the question of what prevents a specific person from using the site, so it helps to discuss them with the team through examples, not just as formal items.

For a commercial website, a sensible goal is level AA for key pages and scenarios: the home page, service pages, catalogue, enquiry forms and checkout.

Visual accessibility: contrast, type, colour

• Contrast. For normal text, WCAG requires a contrast ratio of at least 4.5:1 against the background; for large text, at least 3:1. Light-grey text on a white background is a frequent violation.
• Size and zoom. Body text should be a comfortable size, and the page should work correctly when the browser is zoomed in, without losing content.
• Colour is not the only signal. If a form error is marked only with a red border, a person with impaired colour vision will not notice it. Add text or an icon.
• Links. They should differ from normal text not only by colour, for example by underlining.
• Animations. Avoid flashing elements and respect the system "reduce motion" setting.

These requirements are easiest to build in at the brand identity level: if the brand palette has been checked for contrast, designers do not have to search for a compromise between beauty and readability every time.

Keyboard operation and assistive technologies

Some users do not use a mouse: they move around the page with the Tab key or use screen readers that read content aloud.

• All interactive elements — links, buttons, menus, fields, sliders — must be reachable by keyboard.
• Focus must be clearly visible: designers often remove the outline "because it looks ugly", and users get lost on the page.
• The tab order should follow the logic of the page.
• Modal windows should close with the Esc key and must not "trap" the user.
• Meaningful images need alternative text (alt) describing their content. Decorative images get an empty alt.
• Icon buttons without text (search, cart, menu) need a clear label for screen readers.

An accessible website is not a separate "low-vision version" but a well-made site that is convenient for everyone. Most accessibility requirements are simply signs of good design and code.

Structure, copy and forms

• Headings. A logical h1–h2–h3 hierarchy helps both screen readers and ordinary readers who skim the page.
• Page language. The lang attribute must match the version's language; otherwise a screen reader will read Uzbek text with Russian pronunciation.
• Descriptive links. "More about delivery" is better than ten "Read more" links on one page.
• Plain language. Short sentences, clear terms, lists instead of walls of text.
• Forms. Every field needs a visible label, not just a placeholder that disappears when you type. Errors are described in text: what is wrong and how to fix it.
• CAPTCHA. If you need one, choose options that do not require deciphering distorted text or pictures.

Video, audio and documents

• Add captions to videos — they are used not only by people with hearing impairments but by everyone watching clips without sound on social media and in public places.
• Provide transcripts for podcasts and audio.
• Do not autoplay video with sound, and let users pause any moving animation or carousel.
• Make downloadable documents in a format with a text layer rather than image scans, with headings and bookmarks.

This is especially relevant for price lists, catalogues and manuals: if a document is just an image of a page, neither a screen reader nor a search engine can read it, and a smartphone user cannot search it for a word or copy company details.

How to check your site yourself

1. Keyboard test. Put the mouse aside and go through a key scenario — for example, from the home page to submitting an enquiry — using only Tab, Enter and the arrow keys. Can you see where the focus is? Does everything respond?
2. Automated check. Lighthouse in Chrome and extensions such as axe find some problems: contrast, missing alt, field labels. Remember that only some violations can be detected automatically.
3. Zoom. Zoom the browser to 200% and check that elements do not overlap and content does not disappear.
4. Screen reader. Try the built-in screen reader on your phone or computer — VoiceOver on Apple devices, TalkBack on Android, or the free NVDA for Windows.
5. Real users. If possible, ask older relatives or people who use assistive technologies to test the site.

An accessibility check fits well with a general UX audit — see our UX audit checklist.

Where to start: priorities

You do not have to fix everything at once. A sensible order:

1. Fix text and button contrast, bring back visible focus.
2. Add alt text to meaningful images and labels to icon buttons.
3. Sort out forms: field labels and clear error messages.
4. Check the heading structure and the lang attribute in all language versions.
5. Add captions to key videos.
6. Include accessibility requirements in briefs for designers and developers so new pages are done right from the start.

If you are planning a new site or a redesign, accessibility is cheapest to build in at the design stage. The Dasta Creative team takes WCAG requirements into account when designing and checks key scenarios — see our web design page.