An axe-core scan of ten CometWeb pages found a text contrast problem on our pricing page. Two recorded contrast ratios were 4.49:1 and 3.81:1, both below the required minimum of 4.5:1. One result missed the threshold by just 0.01. Both results were below the threshold, even though only one missed it by a hundredth.
Automated checks cannot establish whether an entire site conforms to WCAG 2.1 AA. Some requirements need keyboard and assistive-technology testing. This guide explains the standard, the differences between its versions and which parts of an accessibility assessment require manual work.
WCAG 2.1: four principles and 13 guidelines
WCAG 2.1 is the W3C's set of accessibility guidelines for web content, published as a Recommendation in June 2018. It extends WCAG 2.0 with 17 success criteria, mostly for mobile use, low vision and cognitive disabilities. The W3C lists them in its overview of what's new in WCAG 2.1. The standard itself and its history are in the WCAG glossary entry.
WCAG groups its criteria under four principles and 13 guidelines. WCAG 2.0 had 12 guidelines, and 2.1 added guideline 2.5, on input beyond the keyboard.
The four WCAG principles are Perceivable, Operable, Understandable and Robust.
Poland's 2019 public-sector act lists them in Article 5(2), under Polish names.
| Principle | What it means | A+AA criteria | Example check |
|---|---|---|---|
| 1. Perceivable | Information and interface can be received through at least one sense the user has | 20 | Informative images have text alternatives and text has enough contrast |
| 2. Operable | The interface can be operated, including without a mouse | 17 | The whole checkout works from the keyboard, with no focus trap |
| 3. Understandable | Content and behaviour are predictable and readable | 10 | A form describes the error and how to fix it |
| 4. Robust | Content works with browsers and assistive technology | 3 | A button exposes a name and role a screen reader can announce |
I counted the "A+AA criteria" column myself in the WCAG 2.1 Recommendation.
Robust has three criteria, but one of them, 4.1.2 Name, Role, Value, applies to every button, field and custom component you put on a page.
Robust and "Kompatybilność" are the same WCAG principle
In Polish the fourth principle has two names: "Solidność" in the W3C's authorised Polish translation from 2021 and "Kompatybilność" (compatibility) in the annex of the 2019 act. In the original it's one principle, Robust.
The catch? In the W3C translation, "Kompatybilność" is the name of guideline 4.1, so when you compare a statute with the standard, match criteria by number.
Levels A, AA and AAA: WCAG 2.1 AA conformance means 50 criteria
Levels are cumulative, so conformance to WCAG 2.1 at Level AA means meeting all 50 Level A and AA success criteria within the scope being evaluated. In the Recommendation itself I counted 30 Level A, 20 Level AA and 28 Level AAA criteria, 78 in total.
Conformance applies to your full pages and complete processes, so if one step of your checkout fails a criterion, the whole process fails. Or you can provide a conforming alternate version with the same information and functionality. Both rules are part of the conformance requirements in the WCAG 2.1 Recommendation.
Level AAA is the highest, and the W3C advises against requiring it for whole sites: "It is not recommended that Level AAA conformance be required as a general policy for entire sites". It's because some content can't meet every AAA criterion, and that's why regulations and most contracts you'll see refer to Level AA.
| Version (published) | Level A | Level AA | Total to meet for AA | Edition I counted from |
|---|---|---|---|---|
| WCAG 2.0 (11 December 2008) | 25 | 13 | 38 | 11 December 2008 |
| WCAG 2.1 (5 June 2018) | 30 | 20 | 50 | 6 May 2025 |
| WCAG 2.2 (5 October 2023) | 31 | 24 | 55 | 12 December 2024 |
The script counted the level labels in the editions you see in the last column. Per the W3C's WCAG 2 overview, later editions of a version keep the same success criteria, so the counts match the 2018 and 2023 versions. Every criterion kept its level in all three.
What WCAG 2.1 added to WCAG 2.0: 17 new criteria
WCAG 2.1 added 17 success criteria: 5 at Level A, 7 at AA and 5 at AAA. The last column tells you whether axe-core 4.13 has a default rule you can run for it.
| Success criterion | Level | What to check in practice | axe-core rule |
|---|---|---|---|
| 1.3.4 Orientation | AA | The page works in portrait and landscape unless one orientation is essential | experimental only |
| 1.3.5 Identify Input Purpose | AA | Personal-data fields carry the right autocomplete, such as email or tel | yes (autocomplete-valid) |
| 1.4.10 Reflow | AA | At a width of 320 CSS pixels content does not need scrolling in two directions | none |
| 1.4.11 Non-text Contrast | AA | Icons, field borders and control states reach at least 3:1 | none |
| 1.4.12 Text Spacing | AA | With increased text spacing, content is not clipped or overlapping | partly (avoid-inline-spacing) |
| 1.4.13 Content on Hover or Focus | AA | Tooltips and hover menus can be dismissed, hovered and do not vanish on their own | none |
| 2.1.4 Character Key Shortcuts | A | Single-letter shortcuts can be turned off or remapped | none |
| 2.5.1 Pointer Gestures | A | Multipoint or path-based gestures have a single-pointer alternative | none |
| 2.5.2 Pointer Cancellation | A | Actions complete on release, not on press, or can be aborted | none |
| 2.5.3 Label in Name | A | A control's accessible name contains the text shown on it | experimental only |
| 2.5.4 Motion Actuation | A | A function triggered by shaking the device also works another way and can be disabled | none |
| 4.1.3 Status Messages | AA | "Added to cart" reaches a screen reader without moving focus | none |
| 1.3.6 Identify Purpose | AAA | The purpose of components and icons can be determined programmatically | outside the measured scope |
| 2.2.6 Timeouts | AAA | Users are told how long inactivity can last before data is lost | outside the measured scope |
| 2.3.3 Animation from Interactions | AAA | Motion triggered by interaction can be disabled | outside the measured scope |
| 2.5.5 Target Size | AAA | Touch targets are at least 44 × 44 CSS pixels, with exceptions | outside the measured scope |
| 2.5.6 Concurrent Input Mechanisms | AAA | The site does not block switching between touch, mouse and keyboard | outside the measured scope |
Each criterion has exceptions described in Understanding WCAG, so check them before you log a failure. Per the W3C's Understanding page for 1.4.10, maps, diagrams or data tables may scroll in two directions because they need a two-dimensional layout.
Of the twelve new A and AA criteria, only two have a default axe-core rule: 1.3.5 and 1.4.12.
Why the gap? Reflow, content on hover, gestures or status messages depend on how the page behaves over time and on what the user sees. You won't reproduce that with a single scan of the DOM.
How I measured this
On 24 September 2026 I ran axe-core 4.13.0 in the Chromium bundled with Playwright 1.62.1, on 10 cometweb.io pages. The sample included both homepages, pricing, a module page, two tools, the contact form, two articles and a glossary entry.
I ran only the 62 default rules tagged for WCAG 2.0 and 2.1 at Levels A and AA. Each of the 50 criteria got one outcome, based on whether a rule maps to it and what that rule returned. The axe-core API documentation explains the tags and the "needs review" results.
The scan saw pages the way you first load them, before you open a menu or dialog or submit a form. The script and full write-up are in the methodology.
Default axe-core rules reach 19 of the 50 WCAG 2.1 AA criteria
As of September 2026, 19 of the 50 Level A and AA criteria in WCAG 2.1 had a default axe-core 4.13 rule, usually covering only part of the criterion. 28 criteria have no rule at all, and three more have only an experimental rule, which doesn't run by default.
Your scanner labels its findings with WCAG criterion numbers, and it's easy to read that as "criterion checked".
By level, 14 of 30 Level A criteria and only 5 of 20 Level AA criteria have a default rule.
An axe-core rule tests only part of a criterion
image-alt will catch an image with no alternative text, but it can't tell you whether "image1.jpg" says anything. The meta-viewport rule, mapped to 1.4.4, only checks whether the viewport tag blocks zooming. According to WCAG, content has to keep working at 200% zoom, and you check that part yourself.
The eleven criteria marked "rules found nothing" passed only their automated part, and only in the state the scan saw.
Most of your work sits with the 28 criteria that lack any rule at all. They include no keyboard trap (2.1.2), focus order (2.4.3), focus visible (2.4.7), error identification (3.3.1) and status messages (4.1.3). You check those by hand, or with a test script that clicks and checks the result.
So I read a clean axe report as "looks fine at first glance", and then I pick up the keyboard anyway.
The cometweb.io scan: one contrast violation and 1,460 elements to review
The violation from the intro was 12 px hint text on my pricing page, in six elements, logged in the raw results as a real template defect. I fixed it the same day with a lighter text colour, and a rescan of the English and Polish pricing pages passed the contrast rules.
On each page the contrast rule handed 88 to 209 elements back to you. Of those 1,460 cases, 1,220 were text on a gradient, where the library can't work out a single background colour.
If your site has dark, shaded sections like mine, expect automation to hand most contrast decisions back to you.
Two more review items came back on every page, and you'll want to check both. One is aria-controls pointing to a menu panel that enters the DOM only once opened. The other is a newsletter privacy link on a gradient.
Automation is good at catching repeatable code errors and regressions between your releases. The rest is your call. The W3C says so plainly in its guide to selecting accessibility evaluation tools: tools can't check every accessibility aspect automatically, and human judgement is required.
4.1.1 Parsing: always satisfied in WCAG 2.1, removed in 2.2
Criterion 4.1.1 Parsing is still at Level A in the current edition of WCAG 2.1, with a note to consider it always satisfied for content using HTML or XML. WCAG 2.2 then removed it as obsolete.
If your audit report still lists duplicate id values as 4.1.1 failures, ask which edition it refers to. A duplicate ID referenced by a label or an ARIA attribute can still fail 1.3.1 or 4.1.2, and axe-core maps its duplicate-id-aria rule to 4.1.2.
WCAG 2.1 or WCAG 2.2: six new A and AA criteria
WCAG 2.2 added nine criteria, six of them at Levels A and AA, and removed 4.1.1 Parsing as obsolete (what's new in WCAG 2.2).
| WCAG 2.2 success criterion | Level |
|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA |
| 2.4.13 Focus Appearance | AAA |
| 2.5.7 Dragging Movements | AA |
| 2.5.8 Target Size (Minimum) | AA |
| 3.2.6 Consistent Help | A |
| 3.3.7 Redundant Entry | A |
| 3.3.8 Accessible Authentication (Minimum) | AA |
| 3.3.9 Accessible Authentication (Enhanced) | AAA |
On a new project, I'd aim straight for WCAG 2.2 AA, for reasons taken from the W3C's WCAG 2 overview and its announcement of the ISO standard:
- content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0, because the W3C designs new versions to be backwards compatible;
- the reverse is weaker, because a site that conforms to 2.1 AA can still fail the six new A and AA criteria;
- since October 2025, WCAG 2.2 is the international standard ISO/IEC 40500:2025, identical to the W3C version of October 2023.
In numbers it's small, 50 to 55 criteria, but it covers situations you've seen on plenty of sites. A sticky header entirely hides the focused element, or touch targets are too small. A form asks for the same data twice, and sign-in requires remembering or transcribing a code, without an alternative.
I show how to test each of the six new criteria in my guide to accessibility audits under WCAG and the EAA.
Which WCAG version applies in Poland and elsewhere
In Poland, WCAG 2.1 at Level AA is a legal duty for public bodies under the digital accessibility act of 4 April 2019. Under its Article 27, the duty reached websites first and mobile apps later.
Outside Poland, your country sets its own version and level. Confirm with a lawyer whether a duty applies to your organisation, and which one.
Public bodies in Poland: the annex to the 2019 act
Article 5(1) of the Polish digital accessibility act requires public bodies to meet the requirements set out in its annex.
The annex is named after WCAG 2.1 and lists Level A and AA criteria, including 1.4.3 Contrast (Minimum), 2.5.3 Label in Name and 4.1.3 Status Messages. The act also requires an accessibility statement, as the Polish government's WCAG 2.1 summary on gov.pl reminds you.
I compared the annex with the WCAG 2.1 criteria by script. It lists 49 of the 50 A and AA criteria (30 A and 19 AA), at the same levels. The only one missing is 1.2.4 Captions (Live).
That gap is consistent with Article 3(2)(1) of the act, which excludes live-broadcast multimedia from its scope. The act doesn't give a reason, and I saved the comparison in annex-pl-2019.json.
Article 5(3) gives you an alternative. The annex requirements are deemed met when a public body provides accessibility taking into account clauses 9, 10 and 11 of EN 301 549 V2.1.2. That's the European standard whose web section is based on WCAG.
Businesses: the European Accessibility Act and EN 301 549
Poland implements the European Accessibility Act through the act on accessibility requirements for certain products and services. It applies in principle from 28 June 2025 to specified products and services, including e-commerce and retail banking.
The requirements come from the act itself, so the 2019 annex doesn't apply to you directly here. You'll find scope with exemptions, plus the WCAG 2.2-based edition of EN 301 549, in the same accessibility audit guide.
How to check whether a site meets WCAG 2.1: 9 steps
A full WCAG 2.1 conformance evaluation is an audit, but I start with a quick review that shows the biggest problems.
- Define the scope and list your page templates and key processes: sign-in, contact form, cart, payment.
- Run an automated test, which will catch some issues, such as missing labels, low text contrast or broken heading structure. You can run it free in Chrome: DevTools > Lighthouse > tick the Accessibility category > Analyze page load. Lighthouse runs axe-core rules, as you can see in its source code.
- Work through the "needs review" results, where the tool admits it doesn't know, so treat each one as a task to close. Check text on gradients or photos by hand at the darkest and lightest point of the background.
- Walk your paths with a keyboard, using Tab, Shift+Tab, Enter, Space and Escape. Focus should always be visible, move in a sensible order and never get stuck.
- Check zoom and reflow. According to WCAG, text has to work at 200% zoom, and the view has to fit a width of 320 CSS pixels (criteria 1.4.4 and 1.4.10).
- Measure contrast in real states: text 4.5:1 (large text 3:1) and non-text elements 3:1, including focus states and error messages. Inactive (disabled) elements, logos and pure decoration are exempt. The contrast checker helps you here.
- Submit your forms with errors, because the error should be described in text, tied to its field and fixable without losing what you typed.
- Check control names, because icon-only buttons need an accessible name, and the visible text on a button should be part of it (2.5.3).
- Record version and level. Without "WCAG 2.1 AA, these pages, these processes, this date", you can't compare the result or put it in an accessibility statement.
For your own review, grab the accessibility checklist, and for a full audit with WCAG-EM sampling and reporting, see the audit guide linked above.
The Accessibility module in CometWeb Insight: the automated part of an audit
The Accessibility module in CometWeb Insight, our website audit app, runs the automated checks across many pages in one run. It:
- checks selected criteria and shows you which elements are affected;
- orders the fixes by impact on users;
- breaks the WCAG principles into a criteria map with a status: checked automatically, issue found, needs manual review, not applicable or no data;
- re-tests the same scope after a fix.
I built the 50-criteria grid above on the same idea as the module's map. The module doesn't issue a WCAG conformance certificate, and manual testing and legal assessment stay with you.
Create an Insight account and run your first accessibility audit.
Three takeaways on WCAG 2.1 AA
- Level AA is 50 criteria, and every Level A and AA criterion counts, across complete processes and with zero tolerance on thresholds.
- Automation touches 19 of them, because default axe-core 4.13 rules usually test only part of a criterion. The other 31 need a person with a keyboard.
- Aim new projects at WCAG 2.2 AA, because content that conforms to 2.2 also meets 2.1 and 2.0, at the cost of five more criteria. You settle the legal duty separately.
Run axe-core on a representative page, then complete a real task using only the keyboard. The contrast finding in my pricing page illustrates why even a small numerical difference can matter.
Frequently asked questions
Is WCAG 2.1 still current?
WCAG 2.1 remains a W3C Recommendation, and regulations such as Poland's public-sector accessibility act refer to it. The latest version, however, is WCAG 2.2 from October 2023. Content that conforms to 2.2 also conforms to 2.1, so new projects are best planned against WCAG 2.2 AA.
Does a private company have to meet WCAG 2.1?
A private company's duty depends on the jurisdiction and the service. In Poland, the 2019 act covers public bodies, while businesses offering specified consumer services, such as e-commerce, fall under the 26 April 2024 act implementing the European Accessibility Act, with requirements linked to EN 301 549. Whether a given company is covered depends on the type of service and on exemptions, for example for microenterprises.
Do other tools check more WCAG 2.1 criteria than axe-core?
Other tools may have rules for a different number of criteria, but none of them can automatically judge what content means or how a page behaves after interaction. I only measured axe-core 4.13, so the 19-of-50 result applies to that tool.
Does an automated test prove WCAG 2.1 conformance?
An automated test can't prove conformance. It checks selected rules in the state of the page it saw, while a person judges whether alternative text is meaningful, how complex components work from the keyboard or how clear error messages are. A clean report is where manual testing starts.
Sources
- W3C, Web Content Accessibility Guidelines (WCAG) 2.1: Recommendation, conformance requirements, levels, the note on 4.1.1; criteria counted by script on 24 September 2026.
- W3C WAI, What's New in WCAG 2.1: the 17 new criteria.
- Polish act of 4 April 2019 on the digital accessibility of public bodies' websites and mobile applications: Articles 3 and 5 and the annex.
- W3C WAI, WCAG 2 Overview: version and update dates, backwards compatibility, ISO/IEC 40500:2025.
- W3C, Authorised Polish translation of WCAG 2.1: Polish names of principles and criteria; translation of 13 April 2021.
- W3C WAI, What's New in WCAG 2.2: new criteria and the removal of 4.1.1.
- W3C WAI, Selecting Web Accessibility Evaluation Tools
- axe-core, API documentation: "incomplete" (needs review) results, tags and experimental rules.
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2
- W3C, Web Content Accessibility Guidelines (WCAG) 2.0
- Polish act of 26 April 2024 on accessibility requirements for certain products and services: Poland's implementation of the European Accessibility Act.
- GoogleChrome/lighthouse, Accessibility gatherer: Lighthouse injects axe-core into the page (axe-core ^4.13.0 is a dependency in
package.json); code as of 25 Sep 2026.
Data and scripts behind the measurement: methodology, criteria counts (JSON), criteria list (CSV), comparison with the Polish annex, scan results, criteria map, counting script. The scan reflects my pages on 24 September 2026 and is not an assessment of their WCAG conformance.