What is web accessibility, and is it now a legal requirement?

Web accessibility means a site can also be used by people with differences in sight, hearing, movement or cognition. It's the answer to the question of whether someone navigating with a screen reader can read your menu, and whether someone who can't use a mouse can fill in your form.

Over the last two years this has stopped being voluntary in a number of markets. Let's take the regulatory side first, then what actually gets done on your site.

Is accessibility a legal requirement?

That depends on where you sell, so the honest answer is: check the regime that applies to you. Two of them come up most often.

If you sell into the European Union, the EU's accessibility regulation began to apply on 28 June 2025, and e-commerce sites aimed at the EU market are assessed under it. If you have customers in Europe, this is the one that concerns you.

If you sell in Türkiye, a Presidential Circular published in the Official Gazette on 24 June 2025 set out a timetable for the accessibility of websites and mobile applications. Alongside public bodies, it covers banks, private hospitals, and organisations providing e-commerce, transport and communications services. The periods set out are one year for public bodies and their affiliates, and two years for the private-sector organisations within scope. The reference is WCAG 2.2, and the circular takes level A as the basis. Organisations are also expected to set up their own accessibility review committees.

If you fall outside both, you may have no legal obligation today. Even so, it's worth adding this: most accessibility fixes improve the site for visitors without any impairment too. These are things worth doing without waiting to be compelled.

What do the WCAG levels mean?

WCAG is the international guidance that defines accessibility criteria. Version 2.2 is the current one, and it defines three conformance levels:

We aim at AA on our own projects. AAA isn't a realistic target for every site; the guidance itself notes that AAA conformance may not be possible for all content.

Where should you look first on your site?

These are the problems that come up most often in audits, in order:

Colour contrast. At AA, the ratio between body text and background should be 4.5:1 for normal-sized text and 3:1 for large text. Designs that put lighter grey on light grey don't clear that threshold. The contrast indicator in your browser's developer tools is enough to measure it.

Alternative text on images. Every image that carries meaning needs alternative text. For purely decorative images the attribute is left empty so the screen reader doesn't read it out needlessly. Writing "image1.jpg" is worse than either.

Keyboard navigation. Put the mouse down and move around the site using only the Tab key. Can you get into the menu, can you close the pop-up, can you submit the form? Every place you get stuck is a fault.

A visible focus ring. While tabbing, it must be obvious which element you're on. Removing that ring for the sake of appearance is a common mistake, and it blinds the keyboard user.

Form labels. Every field needs a real label. Placeholder text written inside the field doesn't count as one; it disappears as soon as you start typing, and the user forgets what they're filling in. Error messages should be given in words, not by red colour alone.

Heading hierarchy. One H1, then a sensible run of H2s and H3s. People using a screen reader move around a page by jumping between headings; if the hierarchy is broken, that method doesn't work. The same structure helps search engines too, which we covered in our SEO guide.

Link text. Links that say "click here" mean nothing once they're taken out of context. The link text should say where it goes.

Video and audio. Videos need captions and audio content needs a text equivalent. Automatic captions often fall short in less widely spoken languages and need reviewing.

Motion control. Animations that play by themselves and rotating slideshows must be stoppable. Switching animations off for visitors who have the reduced-motion preference enabled in their operating system belongs here too.

How do you write alternative text?

This is the most frequently asked practical question, so here's a short run through it. The aim isn't to describe the image but to convey what the image does on that page.

On a product photograph, you write what the product is, not "product on a blue background". If you're using a chart, you write the conclusion the chart shows, not the word "chart". If an image contains text, that text has to make it into the alternative too; otherwise some visitors will never be able to read your offer's conditions. And for an image inside a link, the alternative text should say where the link goes.

There's no need to start with "photo" or "image"; the screen reader already announces that.

Which tools test accessibility?

Automated tools catch some of the problems, not all of them. Audit tools added to the browser will list measurable items such as contrast, missing labels and heading order. The rest needs checking by hand: whether link text is meaningful, whether the reading order makes sense, whether animations are uncomfortable — none of that can be measured automatically.

So we run audits in two stages: an automated scan first, then a manual pass with the keyboard and a screen reader.

Is installing an accessibility widget enough?

The short answer: no.

There are tools on the market that promise compliance by adding one line of code to the site. They generally open a button in the bottom right corner offering settings such as enlarging text or changing contrast. The trouble is that they don't fix the underlying problems. An image with no alternative text still has no alternative text after that button is installed.

The criticism that accessibility practitioners and disabled users' communities level at these tools runs the same way: in some cases they clash with screen readers and make the experience worse. Conformance is built in the page's own markup.

What does this cost?

There are two scenarios, and the difference between them is considerable.

If a new site is being built, accessibility costs almost nothing. The contrast decision is made at the design stage, the labels get written anyway, and keyboard navigation follows on its own from correct markup. Thought about from the start, the extra work stays small.

On a site already live, the work starts with an audit and varies with what's found. A contrast fix might be a day's work; markup broken at theme level might require rewriting. That's why you audit first and then set priorities.

The order of priority usually runs: blocking problems first (a form that can't be completed with a keyboard, a menu that can't be read), then gaps at content level (alternative text, heading structure), and finally the fine adjustments that conflict with the aesthetics.

Where do you start?

There's a test you can run today without installing anything: put the mouse to one side and try to send a quote request on your site using only the keyboard. Open the menu, go to a service page, reach the form, fill it in, send it.

If you can't complete that journey, your site has an accessibility problem — and it is most likely losing you some customers as well.

We build our new projects to a WCAG 2.2 AA target; you can see the scope on the web design page, and write to us for an audit of your current site.