#977: Accessibility conformance Testing (ACT) Rules Format 1.1

Visit on Github.

Opened Jul 24, 2024

こんにちは TAG-さん!

I'm requesting a TAG review of Accessibility Conformance Testing (ACT) Rules Format 1.1.

The purpose of the Accessibility Conformance Testing (ACT) effort is to establish and document rules for testing the conformance of web content to accessibility standards, such as Web Content Accessibility Guidelines (WCAG). These test rules address automated, semi-automated, and manual testing. ACT makes accessibility testing more transparent, and thus reduces confusion caused by different interpretations of accessibility guidelines.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: Ideally you can provide comments in two months from now.
  • The group where the work on this specification is currently being done: Accessibility Conformance Testing Task Force
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Accessibility Guidelines Working Group
  • Major unresolved issues with or opposition to this specification:
  • This work is being funded by:

You should also know that...

[please tell us anything you think is relevant to this review]

Discussions

2024-10-07

Minutes

Matthew: APA is looking into this, haven't finished yet. No concerns so far.

2024-10-21

Minutes

Matthew: this is an fpwd of 1.1... changes highlighted from 1.0. APA is looking at this. from an Architectural perspective I don't think we should be concerned about it. Parts do raise interesting questions... one thing some in the TAG might have experience with. A few small questions that APA will ask for clarifications on. A number of people from different a11y consultancies and other places - good mix of people involved. I think from a TAG PoV it's good.

... One thing that is related: got me thinking about - a lot of a11y is subjectine and dependent on context. But some is very mechanical. All of these rules are plain language rules... but e.g. some custom control has been implemented correctly, there are ways to express that .. Could we represent those by patterns? Just wondering is there anything people have come across that expresses the relationship between DOM structures ...

Martin: I think selectors would do it... :has() is a big change.

Matthew: I think the question is how applicable ... sort of tangential to what ACT is doing...

Matthew to draft a closing comment and we close by end of week

2024-10-28

Minutes

Matthew: Jeffrey & I were discussing... we do think there might be something worth talking about here... Automatable? I've just seen some additional comments.

Jeffrey: this specification is not a technical spec.. It's a guide for how to write specs. I feel like this should not be on the REC track... They don't have a format...

Dan: a guidelines doc...

Yves: WCAG is on rec...

Jeffrey: it's saying "here's how you write a rule to test a web page against"

Matthew: Some parts of WCAG can be tested mechanically .. we have a plurality of different rule sets ... some proprietary. This is an attempt to harmonize... This document is a tech specification for writing those rules... Perhaps it's a novel sort of document for the REC track though it does have MUST, SHOULD, MAY... but you couldn't write code to lint these rules as they are allowed to be written in file formats that lack structure (though in practice, many seem to be written in Markdown, which opens the possibility for linting and migration between rule format versions)... I do understand why it's rec track... but also it could be done in a different way. It's a good piece of work.

we discuss potential comment - Matthew to work with Jeffrey