Accessibility: a site for everyone

Web accessibility is a site’s ability to be used in different ways: with a screen reader, by keyboard, with the sound off. Its basis is WCAG and sound HTML.

Who needs it

Accessibility isn’t “a special version of the site for disabled people”. It means a site that can be used in different ways. Here is who actually reads yours:

• people who can’t see the page and listen to it with a screen reader, or read it with their fingers on a braille display;
• people with low vision, who enlarge the text several times over, or who have a color vision deficiency;
• people who can’t use a mouse: after an injury, with a tremor, or just because their other hand is holding a child;
• people who can’t hear, and everyone watching a video with the sound off on a train;
• people with cognitive differences, who need plain text and a calm order.

Each of us has been on this list: in bright sun a phone screen is unreadable, and with a broken arm the mouse is out of reach. A search engine, too, behaves like the most patient blind reader: it can’t see pictures either and follows the markup. That is why accessible pages are almost always easier to find.

Every year the WebAIM Million study automatically checks the home pages of a million sites, and every year the great majority have errors. The most common are low text contrast, images without alt, fields without labels, and empty links and buttons. They are easy to fix, and you already know how: all of them came up in earlier lessons.

The four principles

The WCAG standard (Web Content Accessibility Guidelines, currently version 2.2) rests on four principles, known by the first letters of their names as POUR:

1. Perceivable: information can be seen or heard. An image has alt, a video has captions, text has enough contrast.
2. Operable: everything can be used from the keyboard, and nobody is rushed.
3. Understandable: the page language is set, the text is clear, behavior is predictable, and form errors are explained in words.
4. Robust: the page works in different browsers and with different assistive software. The best way to get there is to write correct HTML.

Every requirement has a level: A (the minimum), AA (what is usually required) and AAA (the strictest). Aim for AA.

What the law says

Accessibility is also a legal matter, and the rules depend on where your visitors and your business are. In outline, as of 28 October 2026:

• United States. The Americans with Disabilities Act covers state and local governments (Title II) and businesses open to the public (Title III). The Department of Justice’s position is that this includes their websites, and lawsuits over inaccessible sites are common. WCAG AA is the usual yardstick, and a 2024 rule makes WCAG 2.1 AA the formal standard for state and local government sites.
• European Union. The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 to products and services such as e-commerce, banking and e-books, with an exemption for very small service businesses. Conforming to the harmonized standard EN 301 549, which builds on WCAG, is the usual way to show you comply. Public sector sites fall under an earlier directive, 2016/2102.
• United Kingdom. The Equality Act 2010 requires every service provider to make reasonable adjustments for disabled people, which can include changes to a website. Public sector bodies must also meet the Accessibility Regulations 2018, which require a site to be perceivable, operable, understandable and robust and to publish an accessibility statement. The Equality and Human Rights Commission enforces them in England, Scotland and Wales.
• For comparison, Russia has its own national standard for sites, GOST R 52872-2019.

This is general information, not legal advice, and the rules change. For a real site, ask a qualified lawyer, or the authority in your country: in the UK the Equality and Human Rights Commission (for public bodies, the Government Digital Service), in the EU your national market surveillance authority, in the US the Department of Justice’s ADA site, ada.gov.

Check yourself: what does the letter O in POUR stand for?

Operable: everything can be used from the keyboard, and nobody is rushed.

Keyboard: order and focus

Many people use a site without a mouse, with just the Tab key. Tab moves focus (the selected element) to the next link, button or field; Shift+Tab moves back; Enter follows a link, and Enter or Space presses a button. What matters:

• the focus order follows the order of the markup. So put elements in the HTML in the order people read them, rather than moving them around later with CSS;
• the focused element must be visible: the focus outline shows where you are. You must not remove the default outline (outline: none) without replacing it with something just as clear;
• links, buttons and fields receive focus by themselves. A positive tabindex="5" isn’t needed: it breaks the natural order. Two values are fine: tabindex="0" (make something focusable that wasn’t) and tabindex="-1" (take it out of the order but keep it reachable from a script);
• at the very start of the page comes a “Skip to content” link. It leads to main and saves pressing Tab twenty times through the menu on every page. It is usually hidden until it receives focus.

Try it yourself: the diagram has three “buttons” that look alike. Tab through them and press Enter and Space.

Press Tab a few times until focus has passed over all three buttons, and on each one press Enter or Space. Then click them with the mouse. The table below records what happened.

Book now

Book now

Book now

Nothing has been pressed yet.

What it is	Got focus	Fired from the keyboard	Fired by the mouse	What a screen reader says
Native button	no	no	no	“button”
div with a click handler	will never get it	no	no	nothing: to a screen reader this is plain text, not a button
div with role="button" and tabindex="0"	no	no	no	“button”, but it does nothing from the keyboard

Reset

A native button gets focus from Tab, fires on both Enter and Space, and a screen reader knows it is a button. It has all of that out of the box. The others have to be finished by hand: add focus, a key handler, a role. That is why the first rule of ARIA is to use the right native element if there is one.

Check yourself: why is a native button better than a div with a click handler?

It gets focus by itself, fires on both Enter and Space, and a screen reader knows it is a button. With a div you would have to add all of that yourself.

ARIA: when it’s needed and when it isn’t

ARIA (Accessible Rich Internet Applications) is a set of extra attributes that change what a screen reader announces: role (the role), aria-label (the name), aria-describedby (a hint), aria-current (the current item), aria-expanded (open or closed). It is for complex interfaces that have no native element.

The first rule of ARIA: if a native HTML element has the meaning and behavior you need, use it. ARIA only changes how things are announced and adds no behavior: role="button" won’t make a div work from the keyboard. And wrong ARIA is worse than none, because it promises a screen reader something that isn’t there. “No ARIA is better than bad ARIA,” says the W3C.

There is a second half to it: some “complex” interfaces are now native too. A collapsible block is <details> with <summary>, a dialog is <dialog>, a choice from a list is <select>. Use them.

Where ARIA does belong on our page: aria-label on a nav when the page has more than one; aria-describedby to connect a field with its hint; aria-current="page" to mark the current menu item.

Check yourself: does a button role on a div make it usable from the keyboard?

No. The role changes only what a screen reader announces. Focus and the Enter and Space keys would have to be written in a script. It is simpler to use a native button.

Practice

You’ll go through the 2014-era page as if it were someone else’s. What’s needed isn’t hard, and you’ll see each fix in the checks. Then, outside our preview, do one more thing: open your page in a browser, press Tab and go through it without touching the mouse. Can you see where focus is? Do you get stuck in the menu? After that, run Lighthouse from the developer tools, the Accessibility category, and see what it finds.

What was wrong with 2014

Back then accessibility was called “good manners”. Script-driven menus with no keyboard support, “buttons” made of divs, and pale gray text on white were normal. Many sites removed the focus outline because it was “ugly”. Today an inaccessible site can bring a complaint, a lawsuit or a penalty (in the US and the EU this already happens), and WCAG has become the basis of the laws in many countries.