Web accessibility
A page is used by people who never see it the way it was drawn: someone blind listens to it through a screen reader, someone with low vision enlarges it or turns up the contrast, someone works without a mouse — after an injury, or because a tremor makes a mouse useless.
A screen reader does not look at the page as a picture. The browser builds a separate representation of it — the accessibility tree — which states what is a heading, a button, a link or an input field. If something is not in that tree, the screen reader has no way to tell the user about it.
Accessibility defects are ordinary defects: they are reproducible and they have a documented source of requirements behind them. Since 28 June 2025 the requirements of the European Accessibility Act have applied in the EU to a range of digital products and services.
Everything below can be checked by hand: what is needed is the Elements tab — the markup and the Styles panel next to it — the Lighthouse tab, and the keyboard instead of the mouse.
What a screen reader announces
It reads the page in the order the elements appear in the markup, not in the order they are arranged on screen, and for each element it can announce its name and its role: “Buy, button” or “Email, edit field”.
If something only looks like a button but is built from a plain <div> or <span> without the right semantics, a screen reader may take it for ordinary text. Developers sometimes use ARIA — a set of roles and attributes that help state the role, the name or the state of an element for the screen reader: role="button", for instance, says that the element is to be treated as a button. On its own, though, role="button" does not turn a <div> into a real button — the keyboard behaviour still has to be written by hand. This is why so many accessibility defects are invisible in a screenshot and plain to see in the Elements tab.
How to checkSelect the element in the Elements tab and open the Accessibility panel beside Styles: it shows the name and the role the element takes in the accessibility tree — this is the information the browser passes to the screen reader.
Which requirements this page covers
WCAG runs to dozens of success criteria, and no single page covers them all. The three below are the ones broken most often and the ones a tester can check by hand, without special tools: the contrast of the text, operating the page from the keyboard, and alternative text for images. The rest are set out with examples in the WCAG 2.2 quick reference.
Contrast
Text that is too pale against its background stops being readable for low vision, on a dim laptop screen and in sunlight. 1.4.3 Contrast (Minimum), level AA, requires a ratio of at least 4.5:1 for normal text and 3:1 for large text.
How to checkRight-click the text → Inspect, then click the small square in front of the color value in the Styles panel: the colour picker states the Contrast ratio and marks whether it passes AA. Lighthouse reports the same defect as “Background and foreground colors do not have a sufficient contrast ratio”.
Focus and the keyboard
Everything that can be done with a mouse has to be available from the keyboard — 2.1.1 Keyboard, level A — and it has to be visible which element the keyboard is on — 2.4.7 Focus Visible, level AA. The order in which the focus travels has to stay logical — 2.4.3 Focus Order, level A. Tab normally moves the focus between interactive elements: links, buttons and fields. A developer can make other elements focusable as well, with tabindex. Lighthouse does not run this check; it is done by hand.
How to checkPut the mouse aside: Tab moves forward, Shift + Tab back. It has to be possible to reach every control, the focus order has to be logical, and the current element has to stand out. Try using the buttons, links and other controls from the keyboard as well — with Enter or Space.
The alt attribute
Every tag in the markup can carry attributes — name="value" pairs written inside the tag itself that say more about it. On an image, src holds the path to the file and alt holds the alternative text, the picture put into words:
<img src="logo.png" alt="Tallinn Learning logo"> — the attribute is there: the screen reader says “Tallinn Learning logo”.
<img src="logo.png"> — no alt: the screen reader may read out the file name or something else of no use, or convey nothing of what the picture means.
The browser may show alt as well, when the image fails to load. Without it, whatever the picture carried is lost: a caption on a diagram, a “sold out” badge, an icon-only button all stay unexplained. That is what 1.1.1 Non-text Content, level A, exists for.
Three outcomes are different things: alt with text describes what the picture conveys; an empty alt="" deliberately hides a decorative image from the screen reader; no alt at all is the defect above. Judging the text itself is a job for a person — alt="image" passes the automated check and tells the user nothing.
How to checkRight-click the image → Inspect and read the attributes of the <img> tag in the Elements tab.
At the interview
A junior QA interview rarely asks for the details of the standard. What is asked is whether the basic principles are understood and whether the checks can be run by hand. Try answering before opening the answer.
juniorentry-level knowledge
1. What is web accessibility?
Being able to use a site with a range of impairments: a blind user with a screen reader, a user with low vision, someone who cannot use a mouse and works from the keyboard alone.
2. What is WCAG?
Web Content Accessibility Guidelines — the accessibility guidelines for web content. They set out the criteria a site can be checked against, at three levels of conformance:
- A — the basic level.
- AA — the level normally written into requirements.
- AAA — the strictest one.
3. How do you check a site from the keyboard?
Put the mouse aside and walk the page with Tab and Shift + Tab, checking that:
- every button, link and field can be reached;
- the order the focus travels in is logical;
- the element that currently has focus is visible;
- controls can be activated with Enter or Space.
4. What is the alt attribute for?
It holds the alternative text of an image, the text a screen reader can read out.
<img src="logo.png" alt="Tallinn Learning logo"> — an image that carries meaning.
<img src="decoration.png" alt=""> — a decorative one: the empty alt hides it from the screen reader.
What has to be checked is not only that alt is there, but that its text conveys what the image means.
middlea more advanced level
5. What is ARIA for?
Roles and attributes that help assistive technology understand what an interface element is for and what state it is in.
<div role="button">Buy</div> — the role says the element is to be treated as a button.
<button>Buy</button> — a real button: the semantics and the keyboard support are there already.
ARIA does not replace correct HTML. Where a plain <button> will do, it is the better answer.
6. The text on a page is light grey on white. Is that a defect?
It is a checkable requirement rather than a matter of taste: criterion 1.4.3 Contrast (Minimum) at level AA asks for at least 4.5:1 for ordinary text and 3:1 for large text.
How to check: right-click the text → Inspect, then click the swatch in front of the color value in the Styles panel — the picker states the Contrast ratio and whether it passes AA. Lighthouse finds the same defect in its Accessibility category. Below the threshold it is an ordinary defect: reproducible, with a criterion to cite in the report.
Questions on the other topics are collected on the QA interview questions on DevTools page.