Meeting minutes
?
Announcements
3.1.6 Pronunciation - Proposed content to review
Link to issue: w3c/
3.1.6 Pronunciation - Proposed content to review
Applying SC 3.1.6 Pronunciation to non-web documents
This success criterion is problematic to apply directly to non-web documents because not all document formats provide support for a mechanism to identify the specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation. Where the non-web document format provides such a mechanism, the non-web
document should work with these features to the extent the format provides. Doing so would still address the user needs identified in Intent from Understanding Success Criterion 3.1.6.
Applying SC 3.1.6 Pronunciation to non-web software
PhilDay: Updated with additional note to problematic for closed
This success criterion applies as written as described in Intent from Understanding Success Criterion 3.1.6.
NOTE (FOR NON-WEB SOFTWARE)
Help is a mechanism for software that can provide definitions of words or phrases. This would address the user needs identified in Intent from Understanding Success Criterion 3.1.6.
NOTE (FOR NON-WEB SOFTWARE)
See also the Comments on Closed Functionality.
And in SC problematic for closed:
3.1.6 Pronunciation - This success criterion is problematic to apply to ICT with closed functionality as support may not be available for a mechanism to provide the specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation. However, if the ICT with closed functionality has a help
function, this can be used as a mechanism for software that can provide definitions of words or phrases. This would address the user needs identified in Intent from Understanding Success Criterion 3.1.6.
POLL: Should we include a note for SC problematic for closed as in proposal, or remove this note from 3.1.4 and 3.1.6 entirely? Answer Yes to keep the note, No to remove.
bbailey: Seems we can get away without the note
PhilDay: 3.1.3 doesn't have it, 3.1.4 does
Daniel: We should adjust to what we did in the previous one
Daniel: not feel strongly - just keep consistent
loicmn: As long as the closed functionality has a help system and the help system covers it, the SC is met
PhilDay: Some don't have help systems
loicmn: But that's not because they're closed, thats more a usability problem
… Other software with open functionality may also have problems to meet this, not specific to closed
Loic - don't think we need a special note for closed
bbailey: Makes sense. Should we say anything at all?
PhilDay: We could try to remove the note
Applying SC 3.1.6 Pronunciation to non-web documents
This success criterion is problematic to apply directly to non-web documents because not all document formats provide support for a mechanism to identify the specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation. Where the non-web document format provides such a mechanism, the non-web
document should work with these features to the extent the format provides. Doing so would still address the user needs identified in Intent from Understanding Success Criterion 3.1.6.
Applying SC 3.1.6 Pronunciation to non-web software
This success criterion applies as written as described in Intent from Understanding Success Criterion 3.1.6.
NOTE (FOR NON-WEB SOFTWARE)
Help is a mechanism for software that can provide definitions of words or phrases. This would address the user needs identified in Intent from Understanding Success Criterion 3.1.6.
<Zakim> loicmn, you wanted to agree
loicmn: Agree. I think we don't need the closed functionality section
… And we should go back to 3/1/4 and make it consistent
DRAFT RESOLUTION: For 3.1.6 Pronunciation incorporate proposal into the editor’s draft, with edits (remove SC problematic note) as shown in the meeting minutes above
<loicmn> +1
<bbailey> +1
<Daniel> +1
<PhilDay> +1
RESOLUTION: For 3.1.6 Pronunciation incorporate proposal into the editor’s draft, with edits (remove SC problematic note) as shown in the meeting minutes above
DRAFT RESOLUTION: For 3.1.4 incorporate proposal into the editor’s draft, with edits (remove SC problematic note) as shown in the meeting minutes above to make it consistent with 3.1.3 and 3.1.6
<loicmn> +1
<PhilDay> +1
<Daniel> +1
<bbailey> +1
RESOLUTION: For 3.1.4 incorporate proposal into the editor’s draft, with edits (remove SC problematic note) as shown in the meeting minutes above to make it consistent with 3.1.3 and 3.1.6
Structure questions: closed functionality
Link to issue: w3c/
NOTE (FOR NON-WEB SOFTWARE)
See also the Comments on Closed Functionality.
• This links to https://
which is instead in Appendix A: Success criteria problematic for closed functionality
Proposal 0: Keep note unchanged - just link to Comments on closed
Proposal 1: Add the link to Appendix A to the existing note (so each note references both places).
Proposal 2: Replace the existing link (to comments on closed functionality) with the link to Appendix A.
Proposal 3: Move content from Comments on closed functionality into Appendix A (as introductory comments before the SC detail) so all closed functionality content is in one place and replace link.
PhilDay: Some of these links to the general section about closed functionality. I wondered if it'd be better to have them link to the appendix, which is where the details are
… 0: Keep it as-is
… 1: Add a link to appendix A
… 2: Replace the existing link and only link to the appendix
… 3: restructure the document and put all about closed under appendix A
Proposal 1:
NOTE (FOR NON-WEB SOFTWARE)
See also the Comments on Closed Functionality for general guidance, and Appendix A: Success criteria problematic for closed functionality for more specific guidance for individual success criteria.
Proposal 2 and 3:
NOTE (FOR NON-WEB SOFTWARE)
See also Appendix A: Success criteria problematic for closed functionality.
bbailey: There's no quick way to see what the actual comment for the particular SC is
Daniel: Will fix the issue that Appendix A will have anchors to individual bullet points for each SC problematic for closed functionality. Each one will be under its own heading - instead of a big list that is hard to parse.
Daniel: I'll get to fix this before AGWG reviews. Thinking of restructuring the appendix and having every SC on its own heading
Proposal 1 should be modified - have link to comments on closed, and then add a specific link to the heading within Appendix A SC problematic for closed
Daniel: prefer to have the 2 links - nervous about removing the link to the comments on closed
Daniel: Support adding this, not removing the existing link to the general guidance as the document is wildely distributed as-is and that could create confusion
loicmn: Agree
NOTE (FOR NON-WEB SOFTWARE)
See also the Comments on Closed Functionality for general guidance, and HEADING XXX: SC NNN problematic for closed functionality for more specific guidance for this success criteria
NOTE (FOR NON-WEB SOFTWARE)
See also the [Comments on Closed Functionality] for general guidance, and [HEADING XXX: SC NNN problematic for closed functionality] for more specific guidance for this success criteria
<Zakim> loicmn, you wanted to agree with modified proposal 1 and to say editorial at the end
loicmn: quick edit -- success criterion
NOTE (FOR NON-WEB SOFTWARE)
See also the [Comments on Closed Functionality] for general guidance, and [HEADING XXX: SC NNN problematic for closed functionality] for more specific guidance for this success criterion
DRAFT RESOLUTION: For Comments on closed functionality, incorporate proposal 1 into the editor’s draft (add 2nd specific link to heading within appendix A), with edits shown in the meeting minutes above
<bbailey> +1
<loicmn> +1
<PhilDay> +1
<Daniel> +1
RESOLUTION: For Comments on closed functionality, incorporate proposal 1 into the editor’s draft (add 2nd specific link to heading within appendix A), with edits shown in the meeting minutes above
Review of intro to Comments on Level AA
Link to relevant portion of editor’s draft: https://
https://
PhilDay: AAA comments -- My proposal is that the second editor's note becomes part of the text
<bbailey> +1
Proposed change – no longer an editor’s note, just a new paragraph
The following 2 notes are helpful in understanding the Level AAA success criteria and apply as written to non-web software and non-web documents.
<loicmn> +1
<Daniel> +1
DRAFT RESOLUTION: For Comments on Level AAA, incorporate proposal into the editor’s draft, as is
<loicmn> +1
<Daniel> +1
<bbailey> +1
<PhilDay> +1
RESOLUTION: For Comments on Level AAA, incorporate proposal into the editor’s draft, as is
Editorial: Appendix A could use ID
Link to issue: w3c/
Daniel agreed to make these headers
Daniel: list is very long - so splitting into separate sections with separate headings would help
Daniel: This list is difficult to parse, I'll fix it by adding headings for each SC
zakimk, close this item
Do we need separate definitions for document and non-web document?
Link to issue: w3c/
Document: https://
Non-web document: https://
PhilDay: We currently have separate definition for "document" and "non-web document"
… Bruce and Gregg agree we should combine these intoo one definition for "non-web document"
bbailey: Are we still comfortable saying "document" when we are talking about "non-web document"
ACTION: Editors to check for use of "document" without "non-web"
Daniel: We did it for "non-web document and non-web software"
<loicmn> +1 to only define non-web document
bbailey: Agree with not having separate definition
bbailey: If we say "non-web document" and the sentence is clear enough and we later need to repeat it, I think we'd be good saying "document"
Proposal - editors to propose new combined note for non-web documents to address this issue.
PhilDay: We will propose a new combined definition solely for non-web document
ACTION: editors to propose new combined note for non-web documents to address this issue 936
Edits to background and intro to cover level AAA
Link to issue: w3c/
PhilDay: This is a more general comment
PhilDay: We proposed various places were we need to make changes
… I have proposed some minor changes to acknowledge that we now include AAA
… The first two are very easy
… We also should append to important terms that we are now covering AAA
https://
https://
PhilDay: I think it makes sense to either keep a separate glossary items and clarify that they apply to all technologies or roll the min to the previous glossary list
<Zakim> loicmn, you wanted to prefer a single list
loicmn: I think if we're not defining them it makes sense to put all closed together
<bbailey> +1 to loic
<Zakim> bbailey, you wanted to suggest removing “latest”
bbailey: This will be the last version
bbailey: remove the reference to this latest - the current version includes
… I think this should be written as if we're done with it, not giving the feeling that there can be continuation
PhilDay: Good spot
<loicmn> +1 to avoid "latest"
DRAFT RESOLUTION: For Edits to background and intro to cover level AAA proposal into the editor’s draft, with edits shown (combine glossary items, remove latest) as shown in meeting minutes above
<bbailey> +1
<PhilDay> +1
<Daniel> +1
<loicmn> +1
RESOLUTION: For Edits to background and intro to cover level AAA proposal into the editor’s draft, with edits shown (combine glossary items, remove latest) as shown in meeting minutes above
1.3.4 Orientation – editorial on the word “precondition”
Link to issue: w3c/
PhilDay: This is the only place where we use precondition. Daniel suggests to remove it
Proposed change (CHANGE IN CAPS)
Non-web software that is only used on hardware that supports a single display orientation, or where it is an application that is displayed only on hardware that is physically fixed in one orientation (e.g. a digital building directory) FALLS OUTSIDE THE SCOPE OF THIS REQUIREMENT and therefore does not need to support orientation changes.
<bbailey> +1 -- nice edit
<loicmn> +1
<Daniel> +1
DRAFT RESOLUTION: For 1.3.4 Orientation, incorporate the proposal into the editor’s draft, as is
<PhilDay> +1
<loicmn> +1
<Daniel> +1
<bbailey> +1
RESOLUTION: For 1.3.4 Orientation, incorporate the proposal into the editor’s draft, as is
Other comments
PhilDay: Mitch ahs raised a couple of issues in problematic for closed
PhilDay: 946 and 947, I'll try to take a look at these next week
… Now that we are finished with the AAA the only thing left is your PR, Bruce
… If you've got time this week, please take a quick pass at the AAA comments and the changes we made to the other sections
<bbailey> WRT my PR, I corrected syntax, but its still a broken link
Daniel: I'll pick this up with AGWG again now that we have finished them all
bbailey: As per the AAA terms, I don't know where these should be
PhilDay: If we haven't redefined then we should link to WCAG 2
bbailey: Suggest we ask Tamsin to review document for plain language
Daniel: She is expecting to do introduction & background sections.
Bruce: Can we ask Tamsin for review?
Danil: Yes. She uses to go through intro sections, but we can ask her to take a quick pass at the rest of the document to see if there are big issues that need fixing