ACT rules for WCAG 3

Presented by Jean-Yves Moyen

10 February 2026

Jym77

jym@siteimprove.com

Public

@w3c@w3c.social

Who am I?

Jean-Yves Moyen

Siteimprove A/S

Maintainer of Alfa

ACT rules CG co-chair

​

Jym77

W3C Slack

Github

My areas of expertise

• Working in Accessibility testing since 2019.
• Good knowledge of WCAG 2, little knowledge of WCAG 3.

​

• Very technical knowledge…
• “I read CSS specifications for a living”
• I can tell you how an accessible name is computed, not whether it’s descriptive.

​

ACT rules format

ACT rules: format definition.

• WCAG 3 will use ACT rules format 1.1.
• Long list of required items in a rule.
• For this project, focus on the most important only.

​

ACT rules: important bits

• Applicability: where to look?
• Bypass Blocks only applies if there is repeated content.
• Expectations: what to look for?
• Examples: concrete passing, failing, and inapplicable cases.
• Inspired by Test Driven Development.
• Definitions: clarify terms.

​

Example: “Image has name” (1/2)

• Applicability: “This rule applies to HTML img elements and HTML elements that are a semantic img, except if the element is programmatically hidden.”
• “Semantic img”: ARIA role of img.
• “Programmatically hidden”: display: none, or aria-hidden
• Expectation: “Each target element has an accessible name that is not empty, or has a semantic role of none or presentation.”

​

​

Example: “Image has name” (2/2)

• 18 test cases. Each only consist of a single image.
• Passed cases show ways to provide a name: alt, aria-label(ledby), title; and ways to mark the image as decorative: empty alt, role=“none”.
• Failed cases show that the rule applies also to off-screen images, or elements with an explicit role=“img”.
• Inapplicable cases show that the rule doesn’t care about SVG image (which does not mean that WCAG doesn’t care…)

​

ACT rules principles

ACT rules main principle: unambiguous

• ACT rules MUST be unambiguous.

​

• Leave no room for interpretation. Use definitions to clarify terms.

​

• Rely on the specifications (HTML, CSS, ARIA, …)

​

Ambiguous example: “title”

• Success Criterion 2.4.2 Page Titled: “Web pages have titles that describe topic or purpose.”
• Seems simple enough… but… what is a “title”?

​

• ✅ HTML <title> element.
• <h1> element at document start?
• Large, bold, centered text at the top of the document?
• “Subject” field in an email?

​

Act rules secondary principles

• Avoid subjectivity, when possible.
• “descriptive” is subjective, and hard to avoid;
• but what is be descriptive of what MUST be objective.

​

• Keep rules simples and atomic.
• Test part of a guideline; do not depend on other rules.
• Avoid decision trees, or multi-level logic.
• Composite rules exist but should be avoided.

​

ACT rules limitations

• ACT rules are not technology agnostic.
• For now, HTML (+CSS, ARIA, JavaScript, …)
• Later, Mobile, PDFs, ePub, Word, …
• ACT rules are not test procedures.
• Focus on outcomes and conclusion, not on how to reach them.

​

• ACT rules are partial tests (maybe not for WCAG 3).
• ACT rules detect failures, not success.

​

ACT rules can be very technical

• Even simple rules, with definitions expanded, can get deep into technical details.
• “This rule applies to HTML img elements and HTML elements that are a semantic img, except if the element is programmatically hidden.”
• “This rule applies to HTML img elements and HTML elements that [have a role of img], except if the element [has an ancestor in the flat tree with a CSS property display whose computed value is none].”

​

Examples are important

Examples are part of a rule

• Examples in rules are inspired by Test Driven Development.

​

• Vendors can use examples to check their implementation.
• Conversely, implementations validate the rule.

​

• Examples showcase the rule intention and boundaries.
• Similar to, e.g., the Web Platform Tests checking browser implementations and therefore validating the specifications.

​

Testers can implement the rules

• Vendors send an implementation report.
• Testers can run their tool or methodology on the provided test cases; and check their outcome.
• The reports tell how many rules are correctly implemented.

​

Implementations validate the rules

• Having an implementation is a way for testers to “approve” the rule.

​

• A rule with many implementations denotes consensus in the community.

​

ACT Rules are backed by examples

• Even a simple rule, here checking that images have an accessible name, can have a lot of test cases.
• Testers must (nearly) agree on all cases to have a consistent implementation.
• Testers (and rules writers) can argue on precise test cases, whether they satisfy WCAG.

​

WCAG 3 work in practice

Work organisation

• Each WCAG 3 subgroup has one ACT rules TF liaison.
• The subgroup writes the rules, the liaison is here for guidance.

​

• Liaisons meet regularly to discuss problems.
• Liaisons join some subgroups meetings.
• The format may evolve, but we’d rather avoid it.

​

​

Work focus

• Only write rules for HTML (+CSS, ARIA, …)

​

• Follow the rule template
• Start with examples, at least description of the case.
• It often gives focus on the rules.
• For now, reduce number of examples.

​

• Identify which definitions are needed, draft them.

​

Re-use existing work

• Look at existing rules.

​

• Look at existing definitions.

​

• Use the specifications in your definitions.
• E.g., processing the type attribute of input elements is defined in HTML specifications.
• E.g. data/header association in tables is defined in HTML.

​

ACT rules pitfalls

Assumptions and corner cases

• If the rule has too many complicated corner cases (“except if …”), consider using assumptions instead.

​

• If the assumptions are too broad and many real pages fail them, they shouldn’t be assumptions.

​

• Examples of assumptions: no HTTP header for language; no email subject field for title; …

​

Too few examples, too many examples

• A rule with too few examples is often ambiguous (e.g., do out-of-screen images need a name?)

​

• Examples also record decisions, and can be revisited (e.g., are empty headings a problem?)

​

• But too many examples make the rule unreadable for humans.

​

Manual rules vs automated rules?

• ACT rules makes no distinction on how the rule is tested (manual vs automated, actual procedure, …)
• But internally, rules are often considered as “manual” or “automated”.
• So far, we haven’t been good at writing “manual” rules.
• This hopefully only reflects the authors skills…

​

Specifications evolve

• The combobox pattern changes which each version of ARIA…
• What happens for rules that are checking aspects of it?

​

• HTML is a living specification.
• What you look at today might change tomorrow.

​

​

Conclusion

Key takeaways

• Rules MUST be unambiguous!
• Focus on Applicability, Expectations, and a few examples (for the sake of speed).
• Rules will be polished later, take note of where it is needed (placeholder for definitions, descriptions of examples, …)
• Your ACT liaison is here for help!

Jym77

jym@siteimprove.com

Thank you.

​

Questions?

Support us

​

Your support makes a huge difference to our operations as a public-interest non-profit and to make the web work – for everyone. Learn more at: https://www.w3.org/support-us/

@w3c@w3c.social