Technique · conformity assessment · art. 32(1) of the Polish act
Testing: what a machine finds and what only a person can
The act orders you to carry out a conformity assessment of the service (art. 32(1)) and gives you no template for it. Practice has a clear shape all the same: pick a sample of pages, run the tools over them, walk them by hand with a keyboard and a screen reader, then record the non-conformities with their location and a remediation plan. This page describes that process honestly — including what our own analyzer cannot do.
The number worth knowing: automated tools detect — by their own vendors’ estimates — roughly one third of WCAG non-conformities. Not because they are weak, but because most criteria require judging meaning: is this image description true, is this focus order logical, does this error message say what to do. “Zero errors in the scanner” is not conformity and will not hold up in proceedings.
What machines are good at
Things that are measured
Real contrast after the background is composited, touch target sizes, reflow at 320 px, 200 % zoom, the absence of user-scalable=no. These are numbers, and a machine counts them better than a person.
Things that are formal
Missing alt, an unlabelled field, an empty button, a missing lang, duplicate ids, ARIA roles that are not on the list, an aria-labelledby pointing at nothing, positive tabindex, video with no caption track.
Things that are repeated
The same defect on a thousand pages. A scan crosses the whole site in minutes and shows that the problem is in the template rather than on the page — which means one fix repairs all of it.
Things that must be re-checked
A test after every release. Accessibility breaks quietly: a new banner, a new plugin, a new payment integration. A scheduled scan catches the regression before a consumer does.
What no tool will ever detect
- Whether the
alttells the truth. “Photo” passes every automated test and means nothing. An alt reading“red dress, back view”on a green jumper passes just as cleanly. - Whether the focus order makes sense. The markup can be correct while Tab wanders from the basket to the footer and back into the menu.
- Whether a link name is intelligible. “More” has an accessible name. It just does not say more of what.
- Whether an error message helps. “Error 3021” is identified in line with 3.3.1 and useless.
- Whether headings describe the content. A structure can be formally correct and informationally empty.
- Whether the process can be completed. A payment modal that traps focus and does not hand it back only shows up when somebody tries to buy.
- Whether an alternative exists. A chart with no description, a map with no address, a CAPTCHA with no way around it.
Sampling: you do not test “the whole site”
The WCAG‑EM methodology (W3C) describes how to choose a representative sample and is what auditors reach for. The practical short form — the sample should contain:
Pages common to the whole service
Home, search results, sitemap, the 404 page, sign-in and registration, the accessibility statement, contact.
One instance of every template
Category, product page, article, form, data table, a page with media. One example of each pattern — not a hundred product pages.
Complete processes, end to end
Basket → delivery → payment → confirmation. Conformity of a process is indivisible: if one step fails, the whole process fails, not 80 % of it.
A few pages picked at random
A random sample catches what is in no template: a page left over from 2019, a campaign landing page, a PDF uploaded by marketing.
The mobile site and the app
The same journeys on a phone. A native app is a separate assessment — clause 11 of EN 301 549, not clause 9.
A manual test protocol
1. Keyboard only
The whole journey without a mouse. You are checking: can everything be reached, can you see where you are (2.4.7), is the order logical (2.4.3), is there a trap anywhere (2.1.2), does Esc close what Enter opened, does focus come back where it started.
2. A screen reader
NVDA or VoiceOver on one purchase journey. You are checking: headings, link and button names, field labels, announcements of change (basket, validation), expanded states in the menu. How to do it in twenty minutes.
3. Zoom and reflow
200 % text zoom, 320 px width, both orientations. You are checking that nothing disappears, overlaps or forces scrolling in two directions (1.4.4, 1.4.10, 1.3.4).
4. Colour and motion
Greyscale mode: does information carried by colour survive (1.4.1)? With prefers-reduced-motion on: does animation stop (2.3.3)? Carousels: can they be paused (2.2.2)?
5. Forms under stress
Submit an empty form. Enter a malformed e‑mail. Let the session time out. You are checking 3.3.1, 3.3.2, 3.3.3, 3.3.4 and 2.2.1 — and finding out along the way whether your checkout can be completed at all.
6. Content and language
Do the alt texts describe what is in the images? Are abbreviations and terms explained? Is the page language, and the language of foreign passages, marked up (3.1.1, 3.1.2)?
Tools worth having
| Tool | Where it runs | What for |
|---|---|---|
| axe DevTools, WAVE, Lighthouse | browser extension or panel | a quick scan of a single page while you work |
| The “Accessibility” tab in DevTools | any browser | inspecting the accessibility tree: an element’s role, name and state |
| NVDA / VoiceOver / TalkBack | the operating system | manual testing — the only credible answer to “can this be used” |
| A PDF/UA checker | the file | downloadable documents (clause 10) |
| Our analyzer | the whole site, in a real browser | a multi-page scan with code locations, screenshots and a priority list |
Honestly about our own tool: it renders the page in a real browser at three widths, measures real contrast, touch targets, focus, roles and names, and shows where in the code the problem is. It will not judge for you whether an image description is true, whether the focus order is sensible, or whether the thing can be bought. It does the layer where a machine beats a person — so that a person can spend their time on the layer where it is the other way round.
What ends up on paper
An assessment you cannot produce does not exist in proceedings. Documentation that holds up contains: the scope (the URLs in the sample and why they were chosen), the date and method (WCAG 2.1 AA per EN 301 549, the tools, the screen reader versions), the list of non-conformities with criterion numbers and locations, a remediation plan with dates, and the date of the next assessment. The results then feed the accessibility information required by art. 32(2)(1) — the one an enforcement body checks first, because it is visible without logging in.
Repetition is part of the duty: accessibility is a property of the service, not a state on the day of the audit. A sane rhythm is an automated scan after every release and a full manual assessment once a year or after any major rebuild.