Meeting minutes
Announcements
Review issues raised during review of first half of document
Announcements
PhilDay: Next week's meeting will take place, but the 13th we've canceled.
Review issues raised during review of first half of document
PhilDay: We'vebeen reviewing the document during the last fewweeks, noissue raised
Daniel: Haven't reviewed thoroughly, but been working through other content. Have addressed some minor editorial issues & refs to old sections. These have all been fixed.
… Also an SC name was incorrect.
<Zakim> bbailey, you wanted to confirm that we are still waiting on links to individual Problematic for Closed SC?
Daniel: I spotted a fewissues, including an SC name that was incorrect
bbailey: We were waiting on the change in structure for problematic for closed
<bbailey> Good catches Daniel!
PhilDay: That's already ready for review
SC problematic for closed - review proposed change in structure in PR 973
Link to PR: w3c/
Note in SCs that have issues for closed functionality
See also the [Comments on Closed Functionality](#comments-on-closed-functionality) for general guidance, and [Appendix A: Success criteria problematic for closed functionality](#problematic-for-closed-non-text-content) for commentary on the individual success criterion.
And in SC problematic for closed functionality, Each SC is now a separate heading rather than being a list item:
### [1.1.1 Non-text Content](#non-text-content) {#problematic-for-closed-non-text-content}
Depends upon text (or a text alternative) being in a programmatically
determinable form.
This is what it was before:
<li><a href="#non-text-content">1.1.1 Non-text Content</a> — Depends upon text (or a text alternative) being in a programmatically determinable form.</li>
LATEST NOTE from Daniel: For general guidance, see also the [comments on closed functionality](#comments-on-closed-functionality). For commentary on the individual success criterion, see [Success criteria problematic for closed functionality, non-text content](#problematic-for-closed-non-text-content).</div>
PhilDay: Before we had a note. We wanted to keep the general link to problematic for closed, and then add the specific link to the comments on the appendix
GreggVan: Is this going to be under each provision?
PhilDay: Yes, a note undder each SC
GreggVan: If we are pointing to where the thing is listed it should be only the name of the thing
<bbailey> Preview link: https://
<li><a href="#non-text-content">1.1.1 Non-text Content</a> — Depends upon text (or a text alternative) being in a programmatically determinable form.</li>
[Phil shows changes to section structure]
### [1.1.1 Non-text Content](#non-text-content) {#problematic-for-closed-non-text-content}
Depends upon text (or a text alternative) being in a programmatically
determinable form.
<Zakim> bbailey, you wanted to discuss preview link
Link to new SC problematic preview: https://
bbailey: This is address your concerns
… We could enhance it abit more, but it's good as-is
GreggVan: We have A and AA separate from AAA
PhilDay: As in the rest of the document
loicmn: Good for me, I think it's a good improvement
DRAFT RESOLUTION: For SC problematic for closed, incorporate proposal in PR 973 into the editor’s draft, as is
<loicmn> +1
<PhilDay> +1
<bbailey> +1
<Daniel> +1
<GreggVan> +1 :)
RESOLUTION: For SC problematic for closed, incorporate proposal in PR 973 into the editor’s draft, as is
PhilDay: Once Danielfinishes this and wemerge the PR, I'll send an email for you to review the problematic for closed section
PhilDay: The document versus non-web document is another long-standing change that we have pending
GreggVan: I don't think we have any other use of the word "document" other than for "non-web document"
PhilDay: Currently we have two definitions: one for document and another one for non-web document
bbailey: I think we have a couple where we have a long paragraph that start talking about non-web document, and then after that first occurrence we just say document
PhilDay: And I think that's fine
GreggVan: It might be useful to keep the definition of document and then say that in this note when we use document wereally mean non-web document
… Or we could put a note under the definition of non-web document instead
ACTION: PhilDay to add to issue 949 this proposal from Gregg
Just have note under non-web document - stating "all uses of the word document in this note means non-web document".
bbailey: That seems better
GreggVan: This way you would have a glossary and the proper definition
We should go with the 2nd option - just add a note to non-web document
NOTE:
All uses of the word "document" by itself within WCAG2ICT means non-web document.
PhilDay: I'll add into issue 949
<bbailey> proposal: in glossary, add above note to term "Non-web document"
<bbailey> SR can use header navigation
GreggVan: The headings make it an extraordinary long document, makes it difficult for keyboard users
PhilDay: List had other issue, when we have long passages within a list itme it also made it difficult to navigate
<Zakim> bbailey, you wanted to ask about evergreen
bbailey: We hope that this is the last version, right?
PhilDay: There are a couple of places in the text we we have "latest" and I've changed it to "current"
GreggVan: If there's a 2.3 we need to come back an d re-visit this
GreggVan: suggest we change to "this version" rather than "latest version"
ACTION: PhilDay to check document and make editorial change (this version instead of latest version).
<Zakim> bbailey, you wanted to suggest changing "latest" to "2.2 with date"
bbailey: I think isteadof current we should say WCAG 2.2. published [...]
GreggVan: But you also ahve to date the errata. WCAG 2.2 + errata s of whatever date
<bbailey> ...plus errata as of mm/dd/yyyy
PhilDay: I'll work through that
… There's only one or two places in the document
Next steps
PhilDay: We'll meet on the 6, we'll skp the 13, we'll meet on the 20 and we'll ask AGWG for being on the agenda for the 18 if possible