– DRAFT –
WCAG2ICT Task Force Teleconference

Announcements

<bbailey> Link to minutes from Tuesday call where scope of WCAG3 were covered https://www.w3.org/2026/04/21-ag-minutes.html#42ce

<PhilDay> Issues list of level AAA SCs that have nobody assigned: https://github.com/w3c/wcag2ict/issues?q=is%3Aissue%20state%3Aopen%20label%3AAAA%20sort%3Acreated-asc%20no%3Aassignee%20%22Success%20Criterion%22

Update to introduction to address Mitch’s input

<PhilDay> Original issue raised by Mitch, concerning how we define non-web documents: w3c/wcag2ict#852

<PhilDay> • Update from Bruce – PR updated?

<PhilDay> PR: w3c/wcag2ict#883

Bbailey: Looks good.

PhilDay: We are adding a note (see change list in Github).

PhilDay: and some glossary improvements.

Daniel: Minor thing, instances of two spaces so editorial correction needed.

ACTION: Editors to do review of full document for instances of double spaces after a full stop

<PhilDay> DRAFT RESOLUTION: For the section “Interpretation of web terminology in a non-web context”, incorporate proposal from PR 883 into the editor’s draft, as is

<loicmn> +1

<Laura> +1

<GreggVan> +1

<bbailey> +1

<PhilDay> +1

<Daniel> +1

sam +1

RESOLUTION: For the section “Interpretation of web terminology in a non-web context”, incorporate proposal from PR 883 into the editor’s draft, as is

2.3.2 Three Flashes

<PhilDay> Link to issue: w3c/wcag2ict#548

PhilDay: Continuing the discussion from last week with three flashes. We didn't need an additional note but we had discussion about an editorial comma.

<PhilDay> Proposal 1: no extra commas

<PhilDay> Applying SC 2.3.2 Three Flashes to non-web documents and non-web software

<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.2, replacing “Web pages do not” with “non-web document or non-web software does not”.

<PhilDay> With these substitutions, it would read:

<PhilDay> [Non-web document or non-web software does not] contain anything that flashes more than three times in any one second period.

<PhilDay> Proposal 2: extra commas as per Gregg's suggestion

<PhilDay> Applying SC 2.3.2 Three Flashes to non-web documents and non-web software

<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.2, replacing “Web pages do not” with “non-web document, or non-web software, does not”.

<PhilDay> With these substitutions, it would read:

<PhilDay> [Non-web document, or non-web software, does not] contain anything that flashes more than three times in any one second period.

bbailey: all for deferring this to the editors to solve

bbailey: but as two sentences it works but as a compound thing it is not readable

GreggVan: Easy way to solve it "replace with non-webpages do not or non-web software does not"

Daniel: historically whenever possible we combine because it makes a complex document shorter.

Daniel: Acknowledging the issue, we should consider this is an issue elsewhere.

Daniel: Do not think the comma solves this.

ACTION: Editors to open issue to consider similar instances of substitution for non web documents or non web software

<bbailey> I agree that there is an issues, and not addressed by merely adding a comma.

Loicmn: I have been looking through WCAG - only the 3 flashes SC use the sentence, web*

<PhilDay> Proposal 3: separate substitutions

<PhilDay> Applying SC 2.3.2 Three Flashes to non-web documents and non-web software

<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.2, replacing “Web pages do not” with “non-web document does not" or "non-web software does not”.

<PhilDay> With these substitutions, it would read:

<PhilDay> [Non-web document does not] contain anything that flashes more than three times in any one second period.

<PhilDay> [Non-web software software does not] contain anything that flashes more than three times in any one second period.

<PhilDay> • POLL: For 2.3.2 Three Flashes, do you prefer Proposal 1 (without extra commas) or Proposal 2 (with extra commas)? Answer with a 1 for Proposal 1, 2 for Proposal 2, 3, for Proposal 3, or 0 for no preference.

Loicmn: web pages do not. it's only something specific for these two sections.

<PhilDay> POLL: For 2.3.2 Three Flashes, do you prefer Proposal 1 (without extra commas) or Proposal 2 (with extra commas)? Answer with a 1 for Proposal 1, 2 for Proposal 2, 3, for Proposal 3, or 0 for no preference.

GreggVan: I'll take a look at it and see how many instances there are.

<Daniel> https://w3c.github.io/wcag2ict/

<PhilDay> • POLL: For 2.3.2 Three Flashes, do you prefer Proposal 1 (without extra commas), Proposal 2 (with extra commas), or Proposal 3 (separate sentences)? Answer with a 1 for Proposal 1, 2 for Proposal 2, 3, for Proposal 3, or 0 for no preference.

<PhilDay> POLL: For 2.3.2 Three Flashes, do you prefer Proposal 1 (without extra commas), Proposal 2 (with extra commas), or Proposal 3 (separate sentences)? Answer with a 1 for Proposal 1, 2 for Proposal 2, 3, for Proposal 3, or 0 for no preference.

<GreggVan> 3

<loicmn> 3

<bbailey> 3

<Daniel> 3

<PhilDay> 3

<PhilDay> DRAFT RESOLUTION: For 2.3.2 Three Flashes, incorporate proposal 3 into the editor's draft, as is

<Laura> +1

<bbailey> +1

<PhilDay> +1

<loicmn> +1

<Sam> +1

RESOLUTION: For 2.3.2 Three Flashes, incorporate proposal 3 into the editor's draft, as is

2.3.3 Timeout

<PhilDay> Link to issue: w3c/wcag2ict#549

<PhilDay> Applying SC 2.3.3 Animation from Interactions to non-web documents and non-web software

<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.3

<PhilDay> DRAFT RESOLUTION: For 2.3.3 Animation from Interactions,incorporate proposal into the editor’s draft, as is

<bbailey> +1

<loicmn> +1

<Daniel> +1

<Laura> +1

<PhilDay> +1

<GreggVan> +1

<Sam> +1

RESOLUTION: For 2.3.3 Animation from Interactions,incorporate proposal into the editor’s draft, as is

3.3.6 Error Prevention (All)

<PhilDay> Link to issue: w3c/wcag2ict#564

<PhilDay> Applying SC 3.3.6 Error Prevention (All) to non-web documents and non-web software

<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.6, replacing “Web pages that require” with “Content that requires”.

<PhilDay> With these substitutions, it would read:

<PhilDay> For content Web pages that requires the user to submit information, at least one of the following is true:

<PhilDay> Reversible

<PhilDay> Submissions are reversible.

<PhilDay> Checked

<PhilDay> Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

<PhilDay> Confirmed

<PhilDay> A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

<PhilDay> NOTE (FOR NON-WEB SOFTWARE)

<PhilDay> See also the Comments on Closed Functionality.

<PhilDay> Suggested content for SC in Success Criteria Problematic for Closed Functionality

<PhilDay> ICT with closed functionality may not be able to offer this level of error prevention when limited for security. For example, when entering a personal identification number (PIN) on an ATM, the non-web software is not allowed to know the individual digits that were entered, and therefore the user only gets feedback on completion of the PIN.

PhilDay: Applies as written with word substitution and a suggestion/note for why it might be problematic.

<PhilDay> Gregg’s comment: w3c/wcag2ict#564 (comment)

<Zakim> loicmn, you wanted to say that we need to be consistent with 3.3.4

Loicmn: We do have a similar one 3.3.4 which is an error provision. We just can be consistent with the one in AA.

Loicmn: No additional notes. Just word substitution

<PhilDay> Replace web pages with non-web documents and non-web software, as we did for 3.3.4

bbailey: And are we keeping the note under closed functionality?

PhilDay: Note by loicmn that we didn't in 3.3.4

<PhilDay> POLL Should we keep the note for closed functionality, or have no note as per 3.3.4? Yes for note, no for no note

<loicmn> No

<PhilDay> Content for 3.3.4: https://w3c.github.io/wcag2ict/#error-prevention-legal-financial-data

bbailey: note we develop for 3.3.6 should go back and be used in 3.3.4

<PhilDay> POLL: Should we keep the note for closed in 3.3.6, and also add to 3.3.4 (option 1), or have it in 3.3.6 only (option 2), or remove from both (option 3)?

<bbailey> 1

<loicmn> 3 then 1

<Sam> 1

1

<GreggVan> 1

Daniel: Adding this to 3.3.4 includes essential qualifiers vs 3.3.6 does not.

bbailey: 3.3.4 does not have the exception in the body of the SC. That was something we added to ICT.

loicmn: The only difference is that 3.3.4 is restricted to a certain type of data vs 3.3.6 is not restricted.

Loicmn: I don't believe we need the note

PhilDay: ATM example specifically, you can't provide reversible, confirmation, checks.

<bbailey> Its a good note.

Daniel: May be covered by the reversible option.

<PhilDay> POLL: Should we keep the note for closed in 3.3.6, and also add to 3.3.4 (option 1), or have it in 3.3.6 only (option 2), or remove from both (option 3)?

<loicmn> 3

<bbailey> 1

<Daniel> 3

1

but ok with 3.

<Zakim> loicmn, you wanted to explain the example in the proposed note is not submit

daniel: This example is not an example of submission of data.

<GreggVan> 3

bbailey: how about a note mentioning under closed that submitting the pin allows you to resubmit.

Laura: Submit as it's defined, it does get submitted. The way you know it's incorrect it's because it's been submitted, checked, and marked as incorrect
… And it wouldn't be "reversable", it's "repeatable".

<PhilDay> Proposed alternative note: For ICT with closed functionality, an example that meets the intent of reversible is offering the user the ability to submit a password or PIN the second time after an incorrect entry rejected.

GreggVan: It falls under the same logic but it's not the same words, you cannot revert the submission .Agree it's a bad example

Laura: I think it's a great example for why you need the note

<bbailey> i think being able to re-enter pin or pw falls under Checked

Laura: In ATMs that's a great example, you cannot check that you've entered the information

<bbailey> > Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

<PhilDay> For ICT with closed functionality, the user cannot always validate the information before sumission (for example, with entering PIN or password) as it is not validated until after submission. An example that meets the intent of reversible is offering the user the ability to submit a password or PIN the second time after an incorrect entry rejected.

Gregg: We said it has to either be reversable or meet the other clauses

Laura: We're just saying sometimes it cannot be applied due to security checks

bbailey: I don't think it's a failure but I do think it's nice to include a note about ATMs

<Zakim> loicmn, you wanted to say that a PIN or password is not information.... it is identification

Laura: Is it ok if there is no opportunity to re enter the pin?

Bbailey: It's ok to fail WCAG based on the SC

GreggVan: Security "reasons" for not being accessible does not make it accessible.

daniel: There is not real input error because there is no bad format. You're not an unidentified person in the system. Your identification is not correct.

Daniel: there is nothing special for closed system.

<Daniel> +1 to Loíc

Loicmn: There is not real input error because there is no bad format. You're not an unidentified person in the system. Your identification is not correct. There is nothing special for closed system.

<bbailey> i am okay with not having the note

I am ok without the note as well

<PhilDay> DRAFT RESOLUTION: For 3.3.6 Error Prevention (All) incorporate proposal into the editor’s draft, with edits shown (removing notes) in the meeting minutes above

<bbailey> +1

<PhilDay> +1

<loicmn> +1

<GreggVan> +1

<Daniel> +1

<Laura> +1

RESOLUTION: For 3.3.6 Error Prevention (All) incorporate proposal into the editor’s draft, with edits shown (removing notes) in the meeting minutes above

3.3.9 Accessible Authentication (Enhanced)

<PhilDay> Link to issue: w3c/wcag2ict#565

<PhilDay> Applying SC 3.3.9 Accessible Authentication (Enhanced) to non-web documents and non-web software

<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.9.

<PhilDay> NOTE (FOR NON-WEB SOFTWARE)

<PhilDay> See also the Comments on Closed Functionality.

<PhilDay> Suggested content for SC in Success Criteria Problematic for Closed Functionality

<PhilDay> Examples in this SC are problematic for closed systems. A third party password manager is not used in a closed system. Web auth alternatives that rely on biometrics will require a second biometric option, using different biometric features. Two factor authentication can not be made available via a USB on a closed system. Two factor authentication

<PhilDay> via QR codes can be problematic for users who are blind/have low vision.

Laura: More issues with the examples than the content

bbailey: I think whatever we did for 3.3.8 is what we can do for 3.3.9

<Zakim> loicmn, you wanted to say the examples don't meet the SC

greggvan: in that sentence editorial change from "web auth" to "web authentication"

loicmn: same as 3.38.

Agree.

loicmn: if there is something in the note that is useful it should be in both.

ACTION: Laura to check 3.3.8 to make 3.3.9 consistent with that content.

bbailey: Authentication in this context is really re-authentication.

greggvan: I disagree.

greggvan: this is confusing authentication with registration

<PhilDay> GreggVan: Been going through document to look for consistency of word substitution (X or Y) - will send through a word document and open a new issue.