Web accessibility, properly: a practical guide for designers, developers and the people who pay them

I’m colour blind. I can’t tell some reds from some greens, and I’ve spent twelve years choosing colours for other people by contrast ratio rather than by eye. It made me a more careful designer, and it made accessibility something I think about on every project rather than something I bolt on at the end.

This guide is everything I wish clients, designers and developers knew before a project starts: why accessibility matters, what the standard actually asks for, what the law says where I work (Brazil, the EU and Ireland), which problems cause the most harm, what you shouldn’t build, how to test, how to sign the work off, and how to defend the budget when someone asks whether it’s worth it.

One note before we start: I’m a designer and developer, not a lawyer. Every legal reference below links to the official text, and I’ve summarised it as carefully as I can, but for legal certainty on your own project, talk to a lawyer.

Why it matters

Accessibility is about whether people can use what we build. People who are blind or have low vision, who are Deaf or hard of hearing, who can’t use a mouse, who have tremors, dyslexia, ADHD, migraines, a broken arm, a small phone in bright sunlight, a slow connection, or who are simply getting older. Disability isn’t a small edge case: it’s a part of life that most people meet at some point, for a while or for good.

There are three arguments, and you’ll need all of them at some point:

• It’s the right thing to do. If someone can’t book the appointment, pay the bill or read the article, the product has failed them.
• It’s good business. Accessible sites are usually faster, clearer, easier to search and easier to use for everyone. Captions help people in noisy rooms, contrast helps people outdoors, keyboard support helps power users.
• It’s increasingly the law. In Brazil since 2015, for public sector sites in the EU since 2019, and for a wide range of private services in the EU since 28 June 2025.

The standard: WCAG 2.2 AA

The Web Content Accessibility Guidelines are published by the W3C. WCAG 2.2 became a W3C Recommendation on 5 October 2023 (with an updated version in December 2024), and in October 2025 it was also published as the international standard ISO/IEC 40500:2025. When laws and contracts say “accessible”, this is almost always what they point to, directly or through a standard built on it.

WCAG has three levels: A, AA and AAA. Level AA is the one to aim for: it’s what the laws and standards below expect, and it’s achievable for almost any site. AAA is worth reaching for where you can, but it isn’t required as a whole, even by W3C.

The guidelines are organised under four principles, usually remembered as POUR.

Perceivable

People must be able to perceive the content, whatever senses they use.

• Text alternatives for images that carry meaning; empty alt="" for decorative ones.
• Captions for video, transcripts for audio.
• Structure in the code, not only in the look: real headings, lists and tables.
• Colour contrast of at least 4.5:1 for normal text and 3:1 for large text and for the edges of controls and meaningful graphics.
• Colour never as the only way to convey information. (This is the one I feel most personally: a red error border on its own tells me nothing.)
• Content that still works at 200% text size and reflows at 320 CSS pixels wide, without scrolling in two directions.

Operable

People must be able to use every control.

• Everything works with a keyboard, with no traps and a logical order.
• A focus indicator you can actually see — and, new in 2.2, focus that isn’t hidden behind sticky headers, cookie bars or chat widgets (2.4.11).
• Enough time to read and act; anything that moves, blinks or updates on its own can be paused.
• Nothing that flashes more than three times a second.
• Targets of at least 24 × 24 CSS pixels, or enough space around them (2.5.8, new in 2.2).
• An alternative to dragging for anything done by dragging, like sliders and sortable lists (2.5.7, new in 2.2).

Understandable

People must be able to understand the content and how the interface behaves.

• The page language is declared (lang), and changes of language in the text are marked.
• Navigation and components behave consistently across pages; help is in the same place on every page (3.2.6, new in 2.2).
• Forms have visible labels, clear instructions and errors that say what went wrong and how to fix it.
• No asking for the same information twice in one process (3.3.7, new in 2.2).
• No memory or puzzle tests to log in — allow password managers and copy-paste, or offer another way (3.3.8, new in 2.2).

Robust

Content must work with the browsers and assistive technology people use, today and tomorrow.

• Every control has a name, a role and a state that assistive technology can read. Native HTML elements do this for free; custom widgets need ARIA, and ARIA used badly is worse than none.
• Status messages (“Added to basket”, “3 results”) are announced without moving focus.

WCAG 2.2 added nine success criteria in all (six of them at levels A and AA, listed above) and removed one: 4.1.1 Parsing, which modern browsers made obsolete. If your team still works from WCAG 2.1, the six A and AA additions are the gap to close.

The law in Brazil

Brazil has had website accessibility in law for a long time, and it applies to private companies as well as government.

• Lei nº 13.146/2015 — the Lei Brasileira de Inclusão, or Estatuto da Pessoa com Deficiência. Article 63 makes accessibility mandatory on websites run by companies with headquarters or commercial representation in Brazil, and by government bodies, following the best practices and accessibility guidelines adopted internationally. Its first paragraph requires those sites to display the accessibility symbol prominently.
• Decreto nº 5.296/2004 — Article 47 required public administration portals and websites to become accessible (the text speaks of people with visual impairments) within 12 months, and to show an accessibility symbol on their entry pages.
• eMAG — the Modelo de Acessibilidade em Governo Eletrônico. It was made mandatory for federal government sites by Portaria nº 3 of 7 May 2007. The current version, 3.1, dates from 2014 and is based on WCAG 2.0, adapted to Brazilian needs.
• ABNT NBR 17225 — Acessibilidade em conteúdo e aplicações web — Requisitos, launched by ABNT on 11 March 2025. It sets out 146 guidelines, split into requirements and recommendations, with a checklist. According to Ceweb.br, which coordinated the drafting, it follows WCAG 2.2.

In practice: if you build for a company that operates in Brazil, the LBI applies, and meeting WCAG 2.2 AA (which is what NBR 17225 builds on) is the clearest way to show you followed the international guidelines it refers to.

The law in Europe

The Web Accessibility Directive

Directive (EU) 2016/2102 covers the websites and mobile apps of public sector bodies. It has applied to new websites since 23 September 2019, to all websites since 23 September 2020 and to mobile apps since 23 June 2021. Every covered site must publish an accessibility statement — what isn’t accessible and why, with alternatives — and offer a feedback mechanism so anyone can report a problem or ask for content they can’t reach.

The European Accessibility Act

Directive (EU) 2019/882, the European Accessibility Act, is the one that changed things for private businesses. It has applied since 28 June 2025 to a set of products and to services provided to consumers, including:

• e-commerce;
• consumer banking services;
• electronic communications;
• services giving access to audiovisual media;
• e-books and the software to read them;
• air, bus, rail and waterborne passenger transport — their websites, apps, e-tickets and travel information.

A few points that come up in every conversation with clients:

• Microenterprises providing services are exempt: fewer than 10 people, and an annual turnover or balance sheet total of no more than €2 million.
• There are transition periods. Service contracts agreed before 28 June 2025 can run unchanged until they end, for up to five years, and products already in use before that date can go on being used to provide services until 28 June 2030.
• It isn’t only for European companies. It applies to services provided to consumers in the EU.

EN 301 549

EN 301 549 is the European standard for the accessibility of ICT products and services. Version 3.2.1 (2021) is aligned with WCAG 2.1 AA and is the standard used for the Web Accessibility Directive. Version 4.1.1, published by ETSI in September 2026, updates the web, document and software clauses to WCAG 2.2 and covers both directives. At the time of writing it hasn’t yet been cited in the EU’s Official Journal, which is what gives a standard its legal presumption of conformity — so if you’re already working to WCAG 2.2 AA, you’re ahead of it.

Ireland

Ireland transposed both directives:

• the Web Accessibility Directive through S.I. No. 358/2020, with the National Disability Authority as the monitoring body;
• the European Accessibility Act through S.I. No. 636/2023, where enforcement is split by sector: the CCPC for products and for e-books and e-commerce, ComReg for electronic communications and the 112 emergency number, Coimisiún na Meán for audiovisual media services, the Irish Aviation Authority for air transport, the National Transport Authority for bus, rail and waterborne transport, and the Central Bank of Ireland for consumer banking. The NDA has an advisory role.

The problems that do the most harm

WebAIM’s yearly analysis of the top million home pages keeps finding the same handful of failures, year after year. They’re also the ones I find most often in audits, and they’re all fixable:

1. Low-contrast text. Grey on grey, white on yellow, thin fonts on photos.
2. Images without text alternatives, or with alt text that says “image123.jpg”.
3. Links and buttons without a name — icon buttons with no label are the classic.
4. Form fields without labels, or with a placeholder doing a label’s job and vanishing as you type.
5. Missing page language, so screen readers read Portuguese with an English voice, or the other way round.
6. No keyboard access to menus, dialogs, carousels and custom dropdowns — or a focus ring removed with outline: none.
7. Headings chosen for their size, not their level, so the page has no outline to navigate by.
8. Motion that can’t be stopped, and animations that ignore the system’s reduced-motion setting.
9. Error messages that rely on colour, or that appear somewhere a screen reader never hears them.
10. Dialogs and cookie banners that trap focus or hide it underneath.

If you fix these ten, you’ll have removed most of the barriers most people meet.

What not to build

Some of the best accessibility decisions are about what you don’t make, because the browser and the operating system already do it better — with settings people have tuned to their own needs and use on every site.

• Don’t build your own zoom or text-size buttons as the answer to low vision. Browsers zoom every page, and people who need it already know how. Your job is to make sure the layout survives 200% and 400% zoom.
• Don’t build a “read aloud” tool for blind users. Screen readers — NVDA, JAWS, VoiceOver, TalkBack, Narrator — are far more capable, and people know them intimately. Your job is clean semantics so their tools work.
• Don’t build colour-blind filters. Operating systems have colour filters, and a filter on one site doesn’t fix a chart that relies on colour. Your job is to never rely on colour alone.
• Don’t build a “simplified view” as a substitute for a readable page. Browsers have reader modes. Your job is a page that is clear to begin with — and that works in reader mode.
• Don’t override the system’s preferences. Respect prefers-reduced-motion, prefers-contrast and forced colours (Windows High Contrast) by default.

Why overlays are a problem

An accessibility overlay is a script, usually a single line, that adds a toolbar to a site and promises to make it accessible — often “compliant” — automatically. They don’t work, for three reasons:

• They can’t fix the cause. The barriers are in the HTML, the design and the content. A script guessing at alt text or rewriting the page on the fly can’t know what a chart means or what a button does.
• They get in the way. Overlays can clash with the screen readers, magnifiers and settings people already use, which is why many disabled users block them.
• They promise what they can’t deliver. In April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay US$1 million, and barring it from claiming, without evidence, that its automated product could make websites WCAG-compliant. More than a thousand practitioners have signed the Overlay Fact Sheet, which says the same.

A preferences panel that sits on top of a site that is already accessible — and says so honestly — is a different thing. I wrote about building one for this site.

How to test

No single tool finds everything. Automated checkers catch a useful share of problems — contrast, missing names, missing labels — but they can’t tell whether alt text is accurate, whether the focus order makes sense or whether an error message is helpful. Plan for three layers.

1. Automated checks

• axe DevTools in the browser, and axe-core in your test suite so regressions fail the build.
• Lighthouse, built into Chrome, for a quick first look.
• WAVE, which shows the problems in place on the page — good for designers and content editors.

Run them on every template, not only the home page, and in every state: menus open, dialogs open, forms with errors.

2. Manual checks

• Keyboard only. Unplug the mouse. Tab through the page: can you reach and use everything, in a sensible order, and always see where you are?
• Zoom to 200% and 400%. At 400% on a 1280-pixel screen you’re looking at a 320-pixel layout: nothing should be cut off or overlap, and you shouldn’t have to scroll sideways to read.
• Reduced motion and forced colours. Turn both on in the operating system and use the site.
• Contrast. Check every text and control colour pair with a contrast checker — never by eye. (I couldn’t if I wanted to.)

3. Screen readers

Test with at least one screen reader on desktop and one on mobile:

• NVDA with Firefox or Chrome on Windows (free);
• VoiceOver with Safari on macOS and iOS (built in);
• TalkBack with Chrome on Android (built in).

Listen to the page from the top. Do headings make an outline? Do buttons say what they do? Are form errors read out? Does the dialog announce itself and return focus when it closes?

And whenever you can, test with disabled people. Nothing replaces watching someone who uses assistive technology every day try to do a real task on your site.

How to validate and sign it off

Accessibility is easiest to deliver when it’s written into the project from the brief, not audited at the end.

• Put it in the contract. “Conforms to WCAG 2.2 Level AA” is a clear, testable requirement. Name the pages and components in scope, and the browsers and assistive technology you’ll test with.
• Write acceptance criteria per component. For a dialog: focus moves into it when it opens, stays inside while it’s open, Escape closes it, focus returns to the button that opened it, and it has an accessible name. Design reviews and pull requests check against these.
• Test before sign-off, with the three layers above, and record what you tested, how and with what.
• Publish an accessibility statement. Say what standard you target, how the site was tested, what doesn’t yet meet it and why, and how people can report a problem and get a response. For public sector bodies in the EU it’s mandatory; for everyone else it’s simply honest. The statement for this site is an example.
• For software sold to organisations, provide an ACR. A VPAT is a template from the Information Technology Industry Council for documenting how a product meets accessibility standards; a completed one is called an Accessibility Conformance Report, or ACR. The current version, 2.5Rev, comes in editions for WCAG, Section 508, EN 301 549, and an international edition that combines all three. Many procurement processes ask for one.
• Keep it working. Automated checks in continuous integration, accessibility in the definition of done, and a re-test after major changes.

How to defend it to a client

Sooner or later someone asks whether accessibility is worth the time. These are the answers that have worked for me:

• “It’s cheaper now than later.” Accessible design costs little when it’s part of the first wireframe. Retrofitting a finished site — new colours, rebuilt components, rewritten content — costs far more.
• “It’s a requirement, not a feature.” In Brazil since 2015, and in the EU since June 2025 for many consumer services. Your competitors’ customers will notice who can and can’t use their site.
• “It makes the site better for everyone.” Clear labels, good contrast, readable type, fast pages and forms that explain their errors improve conversion for every visitor.
• “It reaches more people.” Every barrier removed is a customer who can finish their purchase, booking or enquiry.
• “It protects the brand.” Being publicly unusable is a reputational risk; being known for getting it right is the opposite.
• “It isn’t a one-off.” Budget for testing and upkeep, the same way you budget for security and performance.

And never promise what an overlay promises. I tell clients exactly what I’ll test against, how, and what’s left to do — in writing.

Tools

Checklist

A short version to keep beside you. It doesn’t replace WCAG, but it catches most problems.

Design

• Every text and control colour pair meets 4.5:1 (text) or 3:1 (large text, control edges, meaningful graphics).
• Nothing relies on colour alone: add text, icons, shapes or patterns.
• Focus states are designed, visible and never hidden behind sticky elements.
• Targets are at least 24 × 24 CSS pixels.
• Layouts are designed for 320 pixels wide and for 200% text.
• Every state is designed: hover, focus, active, disabled, error, loading, empty.
• Motion has a reduced version, and anything that moves on its own can be paused.

Build

• Semantic HTML first: real buttons, links, headings, lists, labels and landmarks.
• lang on the page, and on passages in another language.
• Every image has suitable alt text; decorative ones have alt="".
• Every control has an accessible name, role and state.
• Everything works with a keyboard, in a logical order, with no traps.
• Dialogs manage focus and close with Escape.
• Errors are announced, described in text and tied to their fields.
• Status messages use a live region.
• prefers-reduced-motion, prefers-contrast and forced colours are respected.
• Automated checks run in continuous integration.

Content

• Headings describe the sections under them and follow their levels.
• Link text makes sense on its own — no “click here”.
• Videos have captions; audio has transcripts.
• Plain language, short sentences, clear instructions.

Sign-off

• Tested with automated tools, keyboard, zoom, and a screen reader on desktop and mobile.
• Accessibility statement published, with a way to report problems.
• ACR provided where the client or procurement needs one.
• A plan for keeping it accessible after launch.

Where to start

If all of this feels like a lot, start small: run axe on your three most important pages, fix the contrast and the missing labels, then unplug your mouse and try to complete your site’s main task with the keyboard. You’ll learn more in that hour than in any article — including this one.

And if you’d like a hand, accessibility audits and fixes are part of what I do.