Many web development teams mistakenly view ARIA as optional or a quick fix for faulty HTML. This misunderstanding often results in conformance report violations that could be avoided by following proper authoring rules.
The W3C Accessible Rich Internet Applications Working Group published ARIA in HTML as an updated W3C Recommendation in August 2026. It defines authoring rules for WAI-ARIA 1.2 and Digital Publishing WAI-ARIA Module 1.1 attributes on HTML elements. These rules are essential for conformance checking tools, yet myths about ARIA persist, creating compliance gaps that automated testing quickly identifies.
Here's what your team might misunderstand about ARIA and what the specification actually requires.
Myth 1: ARIA Makes Inaccessible HTML Accessible
Reality: ARIA doesn't fix broken semantics. The primary rule of ARIA use is to avoid it when native HTML can provide the same semantic meaning.
For example, adding role="button" to a <div> instead of using a <button> element complicates accessibility without benefits. The <button> element inherently includes keyboard operability, focus management, and implicit semantics that ARIA alone can't provide. You'd need to manually add tabindex="0", keyboard event handlers for Enter and Space, and focus styles.
Conformance checking tools flag these patterns as errors because ARIA in HTML specifies when native elements must be used instead of ARIA roles. Your development workflow should include a pre-commit check to identify ARIA roles applied to elements with native equivalents.
Myth 2: More ARIA Attributes Mean Better Accessibility
Reality: Redundant or conflicting ARIA attributes create more barriers than they remove.
Adding [aria-label](/glossary/aria-label)="Submit form" to a <button>Submit</button> can cause screen readers to announce both the visible text and the label, or choose one unpredictably. The specification's authoring rules aim to prevent this ambiguity.
Similarly, using both [aria-labelledby](/glossary/aria-labelledby) and aria-label on the same element creates a conflict. The specification defines a precedence order, but relying on it forces assistive technology to make choices your code should have made explicitly.
Conformance checking tools catch these conflicts. Configure your CI/CD pipeline to run these checks before code reaches staging. The updated ARIA in HTML recommendation provides the ruleset these tools need to identify redundant or conflicting attributes.
Myth 3: ARIA Fixes All Custom Widget Problems
Reality: ARIA provides semantics, not behavior. You're responsible for keyboard operability, focus management, and state updates.
Consider a custom dropdown menu. Adding role="menu" and role="menuitem" tells assistive technology what the widget is, but doesn't enable Arrow key navigation or Escape key functionality. Those behaviors require JavaScript event handlers that match the ARIA Design Patterns specification.
The gap between semantic markup and functional behavior is where most custom widgets fail WCAG 2.1 Success Criterion 2.1.1 (Keyboard). Your conformance testing must validate both the ARIA markup and the interactive behavior. Automated tools can verify that role="menu" exists; manual testing with a keyboard confirms that the menu actually works.
Myth 4: Conformance Tools Catch All ARIA Errors
Reality: Automated conformance checking identifies syntax errors and prohibited combinations, but can't evaluate whether your ARIA accurately describes the widget's actual behavior.
A conformance checker will flag <div role="button" aria-checked="true"> as an error because buttons don't have a checked state. That's a syntax violation the tool catches easily.
However, if you build a tab interface with role="tablist", role="tab", and role="tabpanel", the conformance checker validates that these roles are allowed on the elements you've chosen. It doesn't verify that clicking a tab shows the corresponding panel or that aria-selected updates when focus moves between tabs.
Your testing strategy needs both layers. Run conformance checking tools in your build pipeline to catch authoring rule violations. Then conduct manual testing with assistive technology to verify that the ARIA markup matches the widget's runtime behavior.
Myth 5: ARIA in HTML Is Just for Screen Reader Users
Reality: ARIA attributes support multiple assistive technologies and user needs, including voice control, switch access, and cognitive support tools.
When you add [aria-describedby](/glossary/aria-describedby) to link supplemental help text to a form field, you're creating a programmatic relationship that screen readers announce. But voice control software also uses that relationship to let users say "click the help text" to activate associated elements.
The aria-live attribute doesn't just announce dynamic updates to screen reader users. Browser extensions that provide reading assistance or cognitive support rely on live regions to identify content changes that might disorient users.
The authoring rules defined in ARIA in HTML ensure these attributes work consistently across assistive technologies. Violating these rules by placing aria-live on an unsupported element breaks the cross-platform consistency that makes ARIA useful beyond screen readers.
What to Do Instead
Integrate conformance checking into your development workflow before code review. The updated ARIA in HTML recommendation gives these tools the ruleset they need to catch authoring violations early.
Start with the first rule of ARIA: use native HTML elements whenever possible. Reserve ARIA for custom widgets that HTML doesn't support natively, or for adding semantics that HTML lacks, like aria-current on navigation links.
When you use ARIA, validate that the attributes you've chosen are permitted on the HTML elements you're using. The specification defines these combinations explicitly. Your conformance checking tool should reference the updated recommendation to flag prohibited combinations.
Document the expected behavior for any custom widget that uses ARIA roles. This documentation should describe keyboard interaction, focus management, and state updates. Use it as a test script for manual validation after automated conformance checks pass.
Train your development team to distinguish between ARIA's semantic layer and the behavioral layer you implement in JavaScript. Conformance tools validate the markup. Your QA process must validate that the markup accurately describes what the widget actually does.
