RE: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1

  *   I feel like you are conflating the tool reporting of findings with conformance reporting. Both tool manufacturers and template creators are going to have to make their own decisions on how to handle this. To me, the obvious way for tool manufacturers would be to report 4.1.1 as always passing. Actual issues involving poorly formed code will be reported elsewhere, as per the first paragraph.

This seems like a potential oversimplification of the issue.  While I agree the challenges can be overcome in a straightforward manner for a particular provider – getting consistency and agreement from all tool makers and regulatory bodies and all of their constituencies who require WCAG 2.0 and 2.1 dated versions is more of a challenge.  There is always a risk when organizations don’t consider something an issue and others do – especially when the note is not normative which then leads to people continuing some level of testing and addressing to avoid potential implications.

Jonathan

From: Michael Gower <michael.gower@ca.ibm.com>
Sent: Thursday, March 23, 2023 12:38 PM
To: John Foliot <john@foliot.ca>; Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: RE: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1

+1 for the CFC
John,

It’s not our job to solve this for either tool makers or report template creators, but we’ve provided a pretty obvious path.

For 2.2, a testing tool is already going to have to alter how it reports any accessibility issues that result from poorly formed code – typically by correctly reporting them under a different SC where there is a problem. In other words, the mapping of valid  ‘4.1.1’ rules to new SCs (or more accurately, the decoupling of valid rules from 4.1.1) will need to take place for all tools anyway.

For 2.0/2.1 rulesets, exactly the same mappings can take place and be reported.

I feel like you are conflating the tool reporting of findings with conformance reporting. Both tool manufacturers and template creators are going to have to make their own decisions on how to handle this. To me, the obvious way for tool manufacturers would be to report 4.1.1 as always passing. Actual issues involving poorly formed code will be reported elsewhere, as per the first paragraph.

For template creators, such as ITI, they have a number of ways to address this, including doing nothing new for 2.0/2.1, with the assumption that tools will no longer be reporting failures. If they want to more proactively aid consistency, the most likely approach to me would be to have the row marked as Yes/Passes by default, and where the template enforces a dropdrop of options, allow no other choices. They could also possibly create a non-editable comment.

Thanks,
Mike

From: John Foliot <john@foliot.ca<mailto:john@foliot.ca>>
Date: Thursday, March 23, 2023 at 8:18 AM
To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Cc: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: [EXTERNAL] Re: CFC - 4.1.1 Parsing in WCAG 2.0 and 2.1
-1 While adding a non-normative note to the Recommendations does indeed "convey the intent of the group (ignore this SC)" I fail to see how it addresses two critical points of the problem statement: drive-by conformance abuses and
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
-1



While adding a non-normative note to the Recommendations does indeed "convey the intent of the group (ignore this SC)" I fail to see how it addresses two critical points of the problem statement: drive-by conformance abuses and the addition of "busy work", in part due to Section 5.2 Conformance. Unless conformance checking tools have an option to "toggle" 4.1.1 testing on or off, those drive-by abusers will still be getting "reports" that shows 4.1.1 normatively failing (even though it "shouldn't"), and dev teams will still be receiving similar "reports" that there are (or may be) conformance issues related SC 4.1.1. Will the addition of this note spark that ability to toggle 4.1.1 testing on or off with all of the conformance checkers out there? My suspicion is that to get that kind of industry change across the board will require a normative change to the existing Recommendations, which introduces other concerns previously brought forward. JF

On Thu, Mar 23, 2023 at 8:35 AM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Hi everyone,

Call For Consensus — ends Tuesday 28th March at 1PM Boston time.

Following from a previous CFC which did not pass:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2023JanMar/0201.html


We discussed an alternative:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2023JanMar/0282.html


That alternative appears to have support (including from those objecting to the previous CFC).

The change has been implemented here:
https://github.com/w3c/wcag/pull/3116


It adds the proposed note to the SC text, and updates the understanding document. The understanding document states that it has been removed from 2.2 but remains in WCAG 2.0 and 2.1 with a note (and replicates the note there).

If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CfC deadline.

Kind regards,

-Alastair

--

@alastc / www.nomensa.com<http://www.nomensa.com>




--
John Foliot |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |
"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"