Resource guide
Principle 4: Robust
Making sure your site works reliably with assistive technology — now and in the future.
By Calling All Minds·Last updated April 2026
Active criteria
The smallest WCAG principle by count.
Most critical SC
Name, Role, Value underpins everything.
Removed in 2.2
Parsing is no longer required.
Principle 4
About this principle
The Robust principle is the smallest in WCAG 2.2 — just two active criteria — but do not let that fool you. It underpins everything else. If your content is not compatible with assistive technology, none of the other principles matter because people simply cannot access it.
Criterion 4.1.2 (Name, Role, Value) is arguably the most important single criterion in WCAG. It requires that every interactive element on your page can be properly identified by assistive technology. If a screen reader cannot tell that something is a button, or cannot read the label on a form field, or does not know whether a checkbox is checked, that is a 4.1.2 failure.
Criterion 4.1.3 (Status Messages) ensures that important updates — such as "item added to basket" or "form submitted successfully" — are communicated to screen reader users without requiring them to move focus.
4.1.1 Parsing was removed in WCAG 2.2
4.1.1 (Parsing) was removed because modern browsers now handle HTML parsing errors gracefully. Any real accessibility issues caused by invalid markup are already covered by other criteria, particularly 4.1.2. You no longer need to test for this criterion.
Guideline 4.1
Compatible
Maximise compatibility with current and future user agents, including assistive technologies.
Compatible
Interactive elements must be fully identifiable and operable by assistive technology.
For all user interface components, the name and role must be programmatically determined. States, properties, and values that can be set by the user must be programmatically determinable. Notifications of changes must be available to user agents including assistive technologies.
In practice: use semantic HTML. A <button> is a button. A <nav> is a navigation landmark. When you cannot use semantic HTML, use ARIA roles and attributes to communicate the same information. Every custom component — dropdowns, tabs, sliders, date pickers — needs correct ARIA to be usable with a screen reader.
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
In practice: when something changes on the page without a full page reload — a success message, an error count, a loading indicator, an item count update — that change must be announced to screen reader users. Use aria-live regions or ARIA roles such as role="status" and role="alert" to communicate these updates.
How AXS Audit tests Robust criteria
AXS Audit uses a combination of static ARIA analysis, DOM inspection, and keyboard simulation to evaluate 4.1.2 across interactive components. It flags missing names, incorrect roles, and components that lack state announcements — giving you a clear list of what to fix.
AXS Audit
AXS Audit evaluates your website against the full WCAG 2.2 matrix — visual, cognitive, and keyboard criteria that most automated scanners miss. Built by the same team that created this guide.