I guess the choice between the two & three step models is down to whether there is another (vendor neutral) venue that could host the rules formation process.

Is there such a place, or sufficient momentum to create one?

@alastc I think the difference is whether there is an ACT TF to be the middle man - the auto-wag group is the producer of the rules (Wilco should be more specific on that). Whether the community group creates the rules and they go to the AG WG to approve and publish or instead the CG sends to ACT TF who does an initial approval to publish but then sends them to the AG WG to finalize things with a CFC. If it is the latter, it means the ACT TF will continue on as a group for quite some time, though likely meeting less often or more ad-hoc as rules become ready for review.

Another caveat of that is if ACT TF reviews and approves, then Wilco being chair of both may be considered a bit of a conflict, as he works for a tool developer, and would write and then review/approve his own work.

@WilcoFiers My review of the contents here is as follows. If you have questions, let me know. I won't be on the call at least for this week.
Some questions come to mind when I think of the longer term maintenance:
Perhaps there should be a section on rule maintenance to address some of the following:

• How often would there be a scan through the rules for updates needed? Is it only prompted by a problem report? Will update rounds also coincide with some point of standards development (e.g. WCAG 2.2, Silver) and at what point in their process does the work begin?
• What is the method of problem reports/handling? Which group scans and triages new issues?
• Where would feedback/issues on published rules be raised?

Wondering if you feel that the rule development group will be disbanded at some point? If they are not, I would imagine that for #3 if the original author fails to do rule maintenance the task of updating would go to another person in the rule dev. group, not someone in the ACT TF. Either way, it seems that there's a group that continues on indefinitely so we want to make sure that AG WG is aware of that.

If gaps appear between what is being covered in newly created rules and existing Failure Techniques (or Sufficient Techniques) will the expectation be that new Failure Techniques (or Sufficient Techniques) be created, or existing ones amended, to remove inconsistencies.

If yes, who, in each model might be responsible for minimising entropy?

Also, we need to discuss responsibilities around rules being superseded. Say manual rule X is currently appropriate, but a year from now a new proposal shows it can be split into rule X1 and X2, of which both parts are achievable automatically. Someone will need to decide if rule X should be removed, and replaced by X1 and X2; or if X remains, and X1 and X2 are also added. But, then there'll be the question of how to deal with competing tests.

I took a stab at detailing out more specific tasks and steps, as I currently understand need to happen in both models suggested above. Maybe this helps with assessing which model is best:

Rule support:

• Provide a channel for developers of rules to ask questions around the interpretation of WCAG
• Confirm that questions are not already answered by existing Techniques and Understanding docs
• Notify AGWG Chairs about potentially useful questions requiring clarification in AGWG docs
• Track and help shepherd discussion on raised questions, and relay responses back to the sender

Note: Questions on rules may identify gaps and issues in existing Techniques or Understanding docs, which will feed into that separate process for maintaining Techniques and Understanding docs.

Rule submission:

• Review submitted rules for completeness and conformance to the ACT Rules Format specification
• Confirm that the interpretation of WCAG in the rules is not inconsistent with existing AGWG docs
• Analyze relationship between submitted rules and existing Techniques and Understanding docs
• Convert the submitted rule in the AGWG style; stage/install it; and ensure all necessary cross-links
• Notify AGWG Chairs about rules that are potentially ready for AGWG publication approval review
• Track and help shepherd publication and approval review, and relay responses back to the sender

Note: A new rule submission may identify gaps and issues in existing Techniques or Understanding docs, which will feed into that separate process for maintaining Techniques and Understanding docs.

Rule maintenance:

• Continuously document errata, bugs, and other issues reported on rules published by AGWG
• Convey identified issues back to the originating submitter, should that entity still exist / be active
• Regularly assess need for action (update rules, mark rules as superseded or obsolete, etc.)
• Notify AGWG Chairs about the need for changes to existing rules or to the status of existing rules
• Track and help shepherd the change process, and make the corresponding changes to the rules

I agree with the bullets from @nitedog -- currently the rules are loosely related to the WCAG requirements and may not reflect agreement with full interpretation of the SC.
A single rule may contain both some WCAG required facets but also some advisory aspects. It's not clear to someone who fails the rule if it fails WCAG or not. Some assumptions are not fully documented in the rules and must be decided before running the rule. Most rules don't cover an entire SC (which is the right way to do it) -- however, it's not clear what aspects of the SC are covered by the rule and which aspects are not covered and must be tested through some other means including rules that are not yet created. The overlap between the rules and the standards is such that it requires an expert to determine if the results of the rule are sufficient or advisory.

I've updated my initial proposal based on feedback.

@mraccess77 I don't think you should look at assumptions as a way to add "advisory" techniques into a rule designed to test WCAG success criteria. Assumptions are about documenting potential false positives or interpretation differences. Whereas advisory techniques are about things that improve accessibility, while not being part of a success criterion.

Solving problems called out because of assumptions often wouldn't improve accessibility. For example, in color contrast, you need to distinguish between bold and regular text, to determine the minimum contrast ratio. Most of us do this by looking at the CSS font-weight property. Font weight is much easier to determine than actually trying to measure the thickness of a font. If someone uses a bold font without setting CSS font-weight, a tester might incorrectly conclude the font isn't bold. That can produce a false positive, but it isn't advisory never to use bold fonts.

I don't agree that you need an accessibility expert to determine whether or not a rule produced a false positive. That certainly isn't the intent. By looking at the assumptions, any content authors should be able to determine whether or not a result was a false positive. That's why it's important to document the assumptions. If there are rules where you think this isn't the case, we should update those rules.

Hi @WilcoFiers I wasn't suggesting we use assumptions to add advisory requirements. I was saying that some rules have advisory aspects in them and if we don't want that we should remove the advisory aspect from the rule. If we want to create advisory rules they should be clearly separate -- or there needs to be some distinction somewhere to help people know what aspects are and are not hard WCAG failures.

A concern from our side is that if we have a TF whose only job is to do do "admin" or "secretary" work (in the 3-step model), it won't be very attractive for either organisations or people to spend their time and effort there.

What would be the personal development opportunities in that TF?

And why would organisations want to allocate resources to do this type of work rather than to involve themselves in other WGs/TFs/CGs that create the standards for the future?

If we can provide good answers for those two questions, I guess this concern is unnecessary.

I am not finding distinct “two step” and “three step” models.
Is that because @WilcoFiers

I've updated my initial proposal based on feedback

?
If not, please someone hit me with a clue bat!

@bruce-usab Yes, it's because of updates made to the proposal.