ACT Task Force requests review for ACT-Rules Format 1.1 FPWD publication

[daniel-montalvo]

The Accessibility Conformance Testing (ACT) Task Force solicits AGWG review for the ACT-Rules Format 1.1 FPWD publication.
Main changes since ACT-Rules Format 1.0 include:

• (4.) Rule Structure: Accessibility Support and Assumptions section are now subsections of Background.
• (4.4.) Accessibility Requirements Mapping: Accessibility requirements are now categorized as either Conformance requirements or Secondary requirements.
• (4.8.) Background: New optional Related Rules and Other Resources subsections have been added
• (4.11.) Change Log: The Change Log has been renamed to Rule Versions
• 4.14.) Implementations: New section has been added, including a method for determining consistency with ACT Rules
• (7.) Definitions: The Outcome definition is updated to include cantTell and untested
• Overall Links to W3C specifications are updated to their latest recommendation

Please respond with:

• Thumbs up if you agree with this publication
• Thumbs down if you disagree with this publication and rationale as per why you disagree

[WilcoFiers]

You can use this diff to compare the two versions:
https://services.w3.org/htmldiff?doc1=https://www.w3.org/TR/act-rules-format/&doc2=https://w3c.github.io/wcag-act/act-rules-format.html

[dbjorge]

Thanks for the diff, much easier to review that way!

This mostly looks good to me; the only changes that look a bit off to me are the order of outcomes at the end of 4.14.1 and 4.14.3.

As I'm understanding it, 4.14.3 only covers cases where a combination of checks act consistently when their outcomes can be combined as specified by the "multiple outcomes for a test case" logic at the end of 4.14.1. I don't think this covers all the ways that existing implementations actually combine multiple checks together in practice; in axe-core, for example, this would more or less map to how multiple checks in a rule's all configuration would be combined, but it doesn't account for more complex cases involving any/none/combinations. Is that omission intentional?

(edit: retracted above after offline discussion with Wilco; I was making an incorrect assumption about the consistency of what ACT calls a "check" vs what axe-core calls a "check")

I also think the position of cantTell in the ordered list at the end of 4.14.1 is off - as the list currently reads, if one check in a set of checks gave a cantTell outcome and another gave a passed outcome, the aggregate result for determining consistency would be passed, but I think it would be more correct for the aggregate to be cantTell. I think cantTell should probably move up to position 2 in the list (between failed and untested).

[daniel-montalvo]

Hello @dbjorge

I am assuming w3c/wcag-act#558 addressed your standing concern above.

The Task Force will proceed to request formal approval for publication of ACT Rules Format First Public Working Draft.

Let us know if you think your concerned has not been addressed by the aforementioned PR.

Thanks!

Best.

[nayanecom]

The language of the ACT rules format is too complex and needs to be written more plainly. Same can be said of much of the WCAG and associated projects at W3C.

[alastc]

Hi @nayanecom,

Whilst in many cases I'd agree, in this case it is a specification that "defines a format for writing accessibility test rules". It is intended for a technical audience.

Also, this is an update to version 1.0, so asking for a complete re-write now is not something that would be actioned, or prevent publication of version 1.1. After discussion and agreement it could be taken on later, but in this case I'm skeptical that it would be seen as worthwhile.

[daniel-montalvo]

Thanks @nayanecom for commenting on the language issue. We are aware of it and do our best to make language as simple as possible. The outcome of previous discussions about this topic has been that the technical complexity of some of the edge cases makes it difficult to use simpler language, but I do welcome new perspectives on that 😊.

I’d be happy for you to bring up specifics where we can simplify the language in the rules format as well as in the rules themselves. These could then be discussed in the calls and/or via GitHub.

[daniel-montalvo]

Closing this. The purpose of this issue was to request review for publishing the FPWD.