Meeting minutes
<PhilDay> present
<PhilDay> ?
<PhilDay> Hi James. Not sure if you got the Zoom meeting info. It is at https://
<PhilDay> Just saw you join!
Announcements
PhilDay: Welcome to James, thank you for joining.
James: I was involved with WCAG in 2017 or so on the subject of plain language. Making my way back to help out with gaps.
PhilDay: Daniel is in Spain, I'm in the UK/Scotland, everyone else is in the US and GreggVan/bbailey are retired
Daniel: The team is making it easier to take minutes. Request to enable transcription and have the transcripts create minutes.
<PhilDay> +1 for transcript
Daniel: Speak up if you have an issue with that/
<LauraM> +1
<James> +1
<bbailey> +1
Daniel: Silence is affirmation, so enabling transcription.
GreggVan: can't typically hold on to them for after the meeting due to accessibility issues.
<PhilDay> AAA SCs status: https://
PhilDay: New view in github of all AAA success criteria (created by Daniel)
PhilDay: 6 unwritten ones left.
3.3.6 Error Prevention (All)
<PhilDay> Link to issue: w3c/
PhilDay: We reached consensus on this (3.3.6) but asked for it to be made consistent with other SCs.
<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 “Non-web documents and non-web software that require”.
<PhilDay> With these substitutions, it would read:
<PhilDay> For non-web documents and non-web software that require the user to submit information, at least one of the following is true:
<PhilDay> Reversible
<PhilDay> Submissions are reversible.
<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> And in SC problematic for closed:
<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> • POLL: Do you prefer 3.3.6 to have a note for closed or not? Answer 1 to include the note, 0 to remove.
<PhilDay> POLL: Do you prefer 3.3.6 to have a note for closed or not? Answer 1 to include the note, 0 to remove.
GreggVan: Nobody gets feedback when you enter a pin. You get * * * * if you hear it, or if you see it.
<bbailey> i think we should keep note
<PhilDay> SC closed - needs more work - Bruce
bbailey: Was this note specifically called out for software?
<Zakim> PhilDay, you wanted to say password managers covered in other SCs
<GreggVan> 0
<bbailey> 2 -- i want to move it
PhilDay: Password managers are in another SC so lets go back to the poll. 1 to keep, 0 to delete, 2 to do something else.
<PhilDay> 0
<bbailey> 2
<James> 0
<GreggVan> 0
0 or 2
bbailey: the only thing wrong with the note is the characterization of problematic. It's a helpful note.
bbailey: should be under software
<PhilDay> bbailey: suggest we move the comment as a note into Applying 3.3.6
GreggVan: it's not a problem for anybody because everyone gets obscured numbers (not just those who are blind/low vision).
<PhilDay> Rework note - to say for a password - mask the entry as you would for a sighted person
<PhilDay> and then put in non-web software
bbailey: I don't think we need a note in problematic or closed but could be in non web software.
GreggVan: Note would say that this is not a problem?
Daniel: I don't feel this is a problem
<bbailey> i'm fine with no note
GreggVan: eliminate the bad understanding note
GreggVan: this could all go under the cognitive test.
ACTION: LauraM to add a note to non-web software to give the example of PIN / password entry to say it is not a problem - mask the input as you would for anyone else
PhilDay: add note for non web software with information about the example that the input should be masked as for everyone else
PhilDay: Laura to remove the note on SC Problematic for Closed.
<PhilDay> DRAFT RESOLUTION: For 3.3.6 Error Prevention (All) incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (delete SC problematic comments, add note in applying for non-web software to say PIN/password entry is not a problem - use same approach for all)
<bbailey> +1
<LauraM> +1
<James> +1
<Daniel> +1
<PhilDay> +1
<GreggVan> +1
RESOLUTION: For 3.3.6 Error Prevention (All) incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (delete SC problematic comments, add note in applying for non-web software to say PIN/password entry is not a problem - use same approach for all)
3.3.9 Accessible Authentication (Enhanced) – update
<PhilDay> Link to issue: w3c/
<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
<PhilDay> Examples of mechanisms that satisfy this criterion include:
<PhilDay> support for password entry by password managers to reduce memory need, and
<PhilDay> copy and paste to reduce the cognitive burden of re-typing.
<PhilDay> Note (Added) (for non-web software)
<PhilDay> Any passwords used to unlock underlying platform software (running below the non-web software) are out of scope for this requirement since these are not under control of the non-web software’s author.
<PhilDay> Note (Added) (for non-web software)
<PhilDay> There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password when starting, powering on / turning on an ICT (device or otherwise). In such situations, it may not be possible for the non-web software to satisfy this success criterion.
<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> 3.3.9 Accessible Authentication (Enhanced) — There are situations where meeting this success criterion is problematic for ICT with closed functionality:
<PhilDay> Systems that are designed for shared use (such as in a public library) or have closed functionality might block mechanisms typically used to assist the user, such as copying authentication information from a password manager. Instead, an alternative authentication method might be needed, such as an identity card scanner.
<PhilDay> Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may be judged to take legal precedence over Success Criterion 3.3.8 Accessible Authentication (Minimum).
Laura: most of this is derived from 3.3.8 as discussed previously
<PhilDay> Success Criterion 3.3.9 Accessible Authentication (Enhanced).
<bbailey> Looks good.
<PhilDay> Suggested content for SC in Success Criteria Problematic for Closed Functionality
<PhilDay> 3.3.9 Accessible Authentication (Enhanced) — There are situations where meeting this success criterion is problematic for ICT with closed functionality:
<PhilDay> Systems that are designed for shared use (such as in a public library) or have closed functionality might block mechanisms typically used to assist the user, such as copying authentication information from a password manager. Instead, an alternative authentication method might be needed, such as an identity card scanner.
<PhilDay> Where standards for banking or security have authentication requirements that are regulated or strictly enforced, those requirements may be judged to take legal precedence over Success Criterion 3.3.9 Accessible Authentication (Enhanced).
LauraM: typo in the last sentence
Daniel: would rather not say that something takes precedence over accessibility
LauraM: need to change it in both 3.3.9 and 3.3.8 if not appropriate language
GreggVan: we should not mention "Instead alternative method such as identity card scanner". Should not provide a solution/recommendation
GreggVan: Delete last half of the first note and all of the second note.
<Zakim> bbailey, you wanted to ask about moving caveat wrt other laws
bbailey: general thing about security and other laws so maybe don't want it to go here. Could go elsewhere.
<Zakim> PhilDay, you wanted to suggest caveat only applies to minimum
<PhilDay> bbailey: Suggest we might need to handle clashes with other regulatory requirements - they do not necessarily supersede other laws
GreggVan: At the top could mention "as with all accessibility guidelines, they do not necessarily supercede other laws"
PhilDay: more appropriate to put in 3.3.8. Delete it in 3.3.9 and cover in the mandatory one.
GreggVan: I would suggest don't do it for either.
<PhilDay> CONSENSUS: remove last bullet from SC problematic for 3.3.9
Daniel: I don't think we should be telling people that none of this is to override the law
Daniel: we should try not to open this can of worms.
<PhilDay> Suggested content for SC in Success Criteria Problematic for Closed Functionality (edited with Gregg's input - remove alternative authentication method, and delete 2nd bullet)
<PhilDay> 3.3.9 Accessible Authentication (Enhanced) — There are situations where meeting this success criterion is problematic for ICT with closed functionality:
<PhilDay> Systems that are designed for shared use (such as in a public library) or have closed functionality might block mechanisms typically used to assist the user, such as copying authentication information from a password manager.
Daniel: Remove note entirely
<GreggVan> +1
<bbailey> +1
<LauraM> +1
<James> +1
<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
<PhilDay> Examples of mechanisms that satisfy this criterion include:
<PhilDay> support for password entry by password managers to reduce memory need, and
<PhilDay> copy and paste to reduce the cognitive burden of re-typing.
<PhilDay> Note (Added) (for non-web software)
<PhilDay> Any passwords used to unlock underlying platform software (running below the non-web software) are out of scope for this requirement since these are not under control of the non-web software’s author.
<PhilDay> Note (Added) (for non-web software)
<PhilDay> There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password when starting, powering on / turning on an ICT (device or otherwise). In such situations, it may not be possible for the non-web software to satisfy this success criterion.
<PhilDay> NOTE (FOR NON-WEB SOFTWARE)
<PhilDay> See also the Comments on Closed Functionality.
<PhilDay> DRAFT RESOLUTION: For 3.3.9 Accessible Authentication (Enhanced) incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (changes to SC problematic for closed & applying 3.3.9)
<bbailey> +1
<LauraM> +1
<James> +1
<PhilDay> +1
<GreggVan> +1
<Daniel> +1
PhilDay: can we bring this back to AGWG?
ACTION: Daniel to review 3.3.8 SC problematic for closed - to give some guidance on better language for the regulatory clash
LauraM: Should we reopen an issue for 3.3.8.
Daniel: Yes
2.4.12 Focus Not Obscured (Enhanced)
<PhilDay> Link to issue: w3c/
<PhilDay> Applying SC 2.4.12 Focus Not Obscured (Enhanced) to Non-Web Documents and Software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.12.
<PhilDay> NOTE (ADDED) (FOR NON-WEB SOFTWARE)
<PhilDay> This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore
<PhilDay> keyboard traps cannot exist and this success criterion would be satisfied.
<PhilDay> NOTE (ADDED) (FOR NON-WEB SOFTWARE)
<PhilDay> See also the Comments on Closed Functionality.
<PhilDay> And proposed content for SC problematic for closed (derived from 2.4.7):
<PhilDay> 2.4.12 Focus Not Obscured (Enhanced) — Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some ICT with closed functionality may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the user interface
<PhilDay> is designed not to need that. For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, thus there is no need for a visible indicator and this success criterion would be satisfied.
<PhilDay> We have 1 proposal to review, derived from 2.4.11 Focus not Obscured, 2.1.2 No Keyboard Trap, and 2.4.7 Focus Visible.
Daniel: I'd add "handling" or "management" after focus.
"yet not offer any mechanism for focus; " -> "yet not offer any mechanism for focus handling/management;"
<bbailey> looks good
<GreggVan> +1
<GreggVan> +1 with daniel edit
<PhilDay> DRAFT RESOLUTION: For 2.4.12 Focus Not Obscured (Enhanced) incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (changes by Daniel)
<bbailey> +1
<James> +1
<PhilDay> +1
<LauraM> +1
<GreggVan> +1
<Daniel> +1
RESOLUTION: For 2.4.12 Focus Not Obscured (Enhanced) incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (changes by Daniel)
Structure for AAA – placeholders in A/AA, or just a separate section
<PhilDay> Link to issue: w3c/
<PhilDay> Current structure – shown using 1.2.6 as an example
<PhilDay> Taking 1.2.6 Sign Language (Prerecorded) as an example:
<PhilDay> Within Comments on Level A and AA success criteria, we have a note for 1.2.6 Sign Language (Prerecorded) (Level AAA:
<PhilDay> NOTE
<PhilDay> See the Comments on Level AAA Success Criteria.
<PhilDay> This is what 1.2.6 therefore looks like in the section "Comments on Level A and AA success criteria":
<PhilDay> 1.2.6 Sign Language (Prerecorded) (Level AAA)
<PhilDay> NOTE
<PhilDay> See the Comments on Level AAA Success Criteria.
<PhilDay> The note then links to the Comments on Level AAA Success Criteria section, which contains the full comment on 1.2.6 Sign Language (Prerecorded) and how it can be applied to non-web documents and non-web software:
<PhilDay> This is what 1.2.6 looks like in the section "Comments on Level AAA success criteria"
<PhilDay> 1.2.6 Sign Language (Prerecorded)
<PhilDay> (Level AAA)
<PhilDay> Sign language interpretation is provided for all prerecorded audio content in synchronized media.
<PhilDay> Applying SC 1.2.6 Sign Language (Prerecorded) to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
<PhilDay> NOTE 1 (ADDED)
<PhilDay> To date, meeting this success criteria has proven to be infeasible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being produced. As compared to captioning and audio description, sign language interpretation is a very specialized skill. Emerging technologies may, in the
<PhilDay> future, allow translation from text or speech to sign language directly. At that time, those who need sign language could use such an automated translation tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access this content that
<PhilDay> people who are blind have access to by using their screen readers. As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any
<PhilDay> public service content.
<PhilDay> NOTE 2 (ADDED)
<PhilDay> Some pre-programmed interactions (e.g., a game or VR) are considered “synchronized media” because the audio is timed to correspond with specific visual information.
<PhilDay> NOTE 3 (ADDED) (FOR NON-WEB SOFTWARE)
<PhilDay> See also the Comments on Closed Functionality.
<PhilDay> POLL: Which structure do you prefer for level AAA? Answer 1 for the current approach (placeholders in A/AA pointing to detail in separate section), 2 for separate section only, 3 for detail to be in same section as A/AA instead of placeholders, or 4 for something else.
<bbailey> 2 3 1 -- but all okay
<Daniel> 2
<GreggVan> 1 or 3 I n that order
all ok
<PhilDay> Daniel: Some of the links don't work - so they need to checked
GreggVan: good to have the placeholders because it makes it clear that the number is not missing. . . the links need to be correct though. Keep placeholders though.
Daniel: This is already a pretty cluttered document, if we clutter it with placeholders it will make it worse
Daniel: You need to maintain the links
GreggVan: but the TOC will be missing numbers
GreggVan: Not placeholders, they are reference links
Laura: I think it makes it too cluttered if you have duplicated sections
<PhilDay> Gregg would not want to stand in the way - so would accept the consensus, but still prefers to keep the reference links (aka placeholders!)
PhilDay: I would propose that we invite input from AGWG for this since we are a small team and have not reached consensus.
<LauraM> +1
<Zakim> bbailey, you wanted to ask for reminder why there is concern for AAA being inline ?
bbailey: I disagree about sending it back to AGWG.
Greggvan: Settle it here.
PhilDay: so decision is to keep it separate.
<PhilDay> DRAFT RESOLUTION: For Structure for AAA, incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (separate section for AAA, no reference links in A/AA)
<bbailey> +1
<LauraM> +1
<James> +1
<GreggVan> +1
<PhilDay> +1
RESOLUTION: For Structure for AAA, incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (separate section for AAA, no reference links in A/AA)
@daniel can you generate minutes?
ACTION: PhilDay to follow up with GreggVan on issues for next week