Thank you for sending us this review. We see a few different ways that your work could be applied, and be tested. As this document is on the REC track, certain criteria need to be met in order for it to advance. The main one of this is having "at least two independent implementations" of the thing being specified.

There are a number of possible avenues here—we're wondering which you are intending for this document. Some possibilities:

• The status quo: this document is specifying a format for writing ACT rules—in which case, the ACT rules documents themselves would count as implementations. We encourage you to ensure that the specification is precise enough to allow tools to be written that could verify, or 'lint', ACT rules against this spec—these linting tools would then form a test suite that ACT Rules authors could use to verify the rules documents they're writing.

• We also encourage you to publish a REC track document that aggregates the ACT rules as written by the CG—in which case the requirement for them to mature on the REC track would be that accessibility testing tools embodying (or supporting) the rules would be required.

• If you have a goal that manual testing tools should be able to load ACT rules, for humans to use in test procedures (which we encourage) then implementations would be accessibility testing tools that support the loading of ACT rules.

• Some of the ACT rules could be checked entirely mechanically. It's possible that ways could be developed to achieve this that could be used (by a machine) directly, as part of projects such as Playwright, Cypress, and/or Web Platform Tests (which has a somewhat different focus). This would allow the rules (or rather the mechanical checks underpinning them) to be more widely adopted, so we encourage you to investigate this approach in future.

Hi @daniel-montalvo, we are following up on the ACT Rules review this week. We were wondering if any of the avenues suggested above align with the group's plans for this work? If there is any advice on how to proceed along those directions that we can offer, please let us know.

Sorry @matatk this slipped through.

I'll respond below.

• The status quo: this document is specifying a format for writing ACT rules—in which case, the ACT rules documents themselves would count as implementations. We encourage you to ensure that the specification is precise enough to allow tools to be written that could verify, or 'lint', ACT rules against this spec—these linting tools would then form a test suite that ACT Rules authors could use to verify the rules documents they're writing.

In our view, commonly used accessibility checkers are already doing this job, although it'd be desirable that more vendors will join.

Currently, the process is as follows:

• The rules are considered "implementations" of this format specification.
• Everybody can write rules that conform with the format specification.
• There is a set of rules written by the ACT Task Force. Some of them have already been approved by AGWG, others are proposed by the Task Force and will eventually be approved by the Working Group.

Although implementation guidance is always welcome, wouldn't be out of scope for the rules format document itself?

• We also encourage you to publish a REC track document that aggregates the ACT rules as written by the CG—in which case the requirement for them to mature on the REC track would be that accessibility testing tools embodying (or supporting) the rules would be required.

I am not clear on this point. Doesn't the set of rules mentioned above cover this already? In addition to this, there is also Implementation pages that cover how different automated, semi-automated, and manual tools have indeed implemented the rule set.

It's true these are not on Rec track because back in the day it was decided that they'll be more impactful if they're published as resources on the WAI website.

• If you have a goal that manual testing tools should be able to load ACT rules, for humans to use in test procedures (which we encourage) then implementations would be accessibility testing tools that support the loading of ACT rules.
• Some of the ACT rules could be checked entirely mechanically. It's possible that ways could be developed to achieve this that could be used (by a machine) directly, as part of projects such as Playwright, Cypress, and/or Web Platform Tests (which has a somewhat different focus). This would allow the rules (or rather the mechanical checks underpinning them) to be more widely adopted, so we encourage you to investigate this approach in future.

• This is certainly something that could be developed in the future. We have not explored yet how the rules could be used in the context of Playwright or Cipress.
• The group is currently exploring how test cases within rules can contribute to the current accessibility Web Platform Tests. For the moment it's mostly automated, manual, and semi-automated accessibility checkers which are implementing the test cases in the rules.
• There is also work on manual rules (rules that automated checkers cannot currently check by themselves) but these are still not approved by the Task Force, hence not published as Proposed to the AGWG Working Group.

The Task Force Would appreciate any comments if you think these additional pages and resource still don't cover the points you raise.

Thanks for your detailed and helpful reply @daniel-montalvo - this gives us a clear picture of the goals, and this gives rise to some things we'd like you to consider.

As the rules are implementations of the spec (the rules format) it's important that the format be made sufficiently precise such that the rules themselves can be automatically checked against the format. We imagine a linting program would be very helpful to those in the community writing the rules. Here are a few examples (which are not exhaustive) as to how that could be achieved:

• Prescribing a single format in which the rules be written would simplify the process of checking them, and mean probably only one linting program would need to be written.

• Here are some examples of things that would need to be tightened up in the spec in order to make automated linting possible (this isn't an exhaustive list, but hopefully provides a helpful starting point):

  1. The exact names for section headings.

  2. Possibly also the ordering for section headings (though this would be more to keep output consistent for readers).

  3. Specifying the exact strings to use as enum values. E.g. for rule types what would be the exact text string that indicates the rule is either atomic or composite?

  4. Specifying the exact structure - and permitted values - of the accessibility requirements mapping - i.e. how are the 5 fields identified, and what are the allowed values (exact text strings)?

  5. Could expectations (example expectations section) be more tightly specified, such that they could be (in future) loaded into an automated test framework? It seems that this would be possible, and could have significant benefits later on.

Your explanation as to why you are not pursuing REC track for the rules themselves makes sense. You could always pursue it later if it does make sense for the group.

Regarding the possibility of integrating the rules into general testing tools later, including WPT, we're pleased that you're exploring this. Let us know if we can help.

We hope this helps clarify things - we are keen to hear your thoughts, and provide any further clarification or advice that we can on this, so we will keep this thread open.

Thanks for your suggestions about this, @matatk.

This is indeed a great idea. We already have a good number of tests in the ACT-rules.github.io repo. Going with strings only as a way to make these normative may raise some i18n concerns. It seems the only way to go about this would be coming up with normative prose semantically, for example through an RDF schema, which is quite an undertaking given current group resources.

We are assuming this is not a blocker for the current 1.1 version. This overall sounds like a good idea to pick up in a future ACT Rules Format version, and we’d be willing to explore potential approaches for this when the time comes for a 2.0 version.

@matatk Have you had a chance to look at Daniel's response? We would like to have confirmation that TAG is on board with this approach before we process to CR.

We talked about this in our breakout this week: We are supportive of this work, and we are happy for the 1.1 version to go to CR.

We're pleased that you're keen to explore the specificity issues that we raised in a future revision (ideally the next after 1.1). As the spec you're writing is about the format of the rules, then rule documents themselves don't constitute tests of the spec: a linter that can check any given rule documents against the format would constitute a test for the format's spec.

We agree that it's important to ensure there are no internationalization concerns. There are ways this could be achieved whilst still fulfilling the need to make the format's spec more precise, and we'd be happy to advise on that later.

We're closing this review with the satisfied with concerns label in order to confirm that we support the work you're doing, and we hope to work with you in future to address the specificity issues we raised.

Thank you again for your review request, and for the important work your group is doing.