Meeting minutes
Announcements
maryjom: AG WG still working on charter.
Most were informative, colour contrast might be normative
GreggVan: Flash & seizure - discussion at last AG WG. Flashing is a bigger issue than just for people who have seizures.
… Also with higher contrast HDR - you can create a very bright flash which is even more problematic.
Just a single flash could cause issues
Also another option for another module could be multi-media
GreggVan: Flashing can occur in an interface - can be more subtle and still cause problems.
<Zakim> bbailey, you wanted to mention possible AG misunderstanding of WCAG2ICT work
bbailey7: Wanted to mention on recent Tuesday call - asked if WCAG2ICT was working on WCAG 2.3 - there was some confusion
maryjom: Charter is not clear - doesn't say exactly what WCAG2ICT are doing this time - language was the same
GreggVan: Assuming WCAG3 will apply more broadly than web. When there is a WCAG3 - it will try and keep in mind lessons from WCAG2ICT, but there will probably still need to be WCAG3ICT.
Survey Results for Level AAA SCs
Survey on level AAA: https://
Survey results: https://
<bbailey7> +1 that wcag2ict work has significantly informed wcag2-issues TF and WCAG3 development
Updated PR for adding AAA criteria
maryjom: Just recap on last week. Mary Jo created the PRs as discussed last week.
<maryjom> Link to PR 827: w3c/
First one was for adding PR for adding AAA criteria
GreggVan: clarifying what the PR included.
maryjom: We decided on proposal 3 - separate section, but links in the main section to keep the context
maryjom: Did change the title of the Comments by Guideline & SC. Now Comments on Requirements by Guideline & SC.
<bbailey7> thank you for filling out more AAA material -- that makes it much easier to understand implication of the direction we're going
If you don't like the heading names, please raise it today so we can discuss
[maryjom sharing screen - displaying PR 827 netlify preview]
Have included (level AAA) in the heading as it is not included in the text
Currently have included the titles for the structure (e.g. guidelines) to give context for each AAA criteria
bbailey7: Thought the heading name was to be comments on, not recommendations for
GreggVan: Is it going to be this spaced out in the final - there is a lot of white space?
maryjom: This is driven by the W3C template.
PhilDay: Thought we should call AAA section "Comments on recommendations ...." to keep consistency
maryjom: Or we could do "Comments on AAA"
GreggVan: What if top one says "Comments on A and AA" and bottom is "Comments on AAA"
GreggVan: Or could have "Comments on Requirements"
maryjom: Since original ICT we had Comments by Guideline & SC
<Zakim> bbailey, you wanted to say its awkward because the whole document is a recommendation
bbailey7: Uncomfortable with recommendation in the heading - as WCAG2ICT is just a recommendation.
We can refer to A & AA as requirements, AAA as recommendations.
Think it should be comments on level AAA
bbailey7: Just don't like "recommendation" in heading for AAA
maryjom: Also W3C has a specific meaning for recommendation so we should avoid overloading that word.
Consensus: Comments on level A & AA SC / Comments on Level AAA SC.
bbailey7: Likes having the heading be the same as the previous publication.
GreggVan: Suggest we go with a first pass of title into the document and then move on to cover content
There is another PR - covering how AAA appears in closed
<maryjom> Sc problematic for closed: https://
[maryjom sharing screen to show SC problematic for closed with new AAA placeholder content]
It might help to have a sub-heading - to call out level A & AA. Then AAA is more consistent
And easier to navigate between the 2 sub-sections
Introductory text has been proposed as well
bbailey7: Think "this is especially true for non-web content" in the preamble. Language needs to be tweaked to make it strong enough - AAA in non-web - likely to not work. Closed is even worse
GreggVan: True for systems without a user agent. Especially true for closed systems
GreggVan: assistive technology, browser, and/or platform support
or mention that platform support includes browsers
maryjom: Will add a sub-heading for level A & AA to make navigation easier
<PhilDay> +1 for sub-heading
Then will put this out for survey so we can modify on language if we need
1.2.6 Sign Language (Prerecorded) (Level AAA)
<maryjom> • Link to question 4: https://
<maryjom> Link to issue 532: w3c/
2 proposals for this - that were in the Google doc
<maryjom> Google doc link: https://
2 people preferred proposal 2, 1 preferred proposal 1. Gregg had some suggested chagnes
GreggVan: edited his note - modify "on the planet" to "worldwide"
… It will also go away with automated sign language
If you need a 'sign language reader' then it should be a similar thought process to how we handle other AT (like screen readers).
<maryjom> Gregg's proposed Note 1: Note 1 (Added)
<maryjom> With current technologies, providing sign language for all synchronized media is a labor-intensive and there are not enough sign language interpreters worldwide to handle content generated in a single day making it technically impossible to require for all content. Developing technologies will fairly soon allow translation from text or speech to
<maryjom> sign language directly - at which time those who want sign language could use such a translator like people who are blind use a screen reader which they select or is built into platforms they use to view web content. However until the latter occurs, providing sign language interpretations is immensely helpful for native sign language users
<maryjom> especially for any public service content.
Gregg's comments were to replace the notes in proposal 2
costly is not a good reason for putting something in AAA, so we need to change this language
maryjom: May not be feasible due to lack of sign language interpreters or some other practical considerations
LauraM: Question I would have - is reason that sign language is not as critical - not just because it is not feasible - but there are alternatives that are more reasonable accommodation than the massive infrastructure needed for sign language interpretation.
GreggVan: Problem - if you are native in sign language may not read English - it is a foreign language to them.
LauraM: When we talk about accommodations that are not feasible - would this fit in that category?
… Reason that it is not a A or AA requirement - it is difficult to do until systems exist that can automate sign language interpretation.
maryjom: Made some changes to the proposed text, took some of Gregg's content, shortened it, and put it into proposal 2
bbailey7: Do we have to say why it is infeasible? We could just say it is presently infeasible.
GreggVan: Think it helps to explain why
<maryjom> With current technologies, providing sign language for all synchronized media is a labor-intensive process. In the absence of reliable automated methods to produce sign language interpretation, it is not technically feasible to require for all audio content to have sign language interpretation, especially where non-web documents and software that
<maryjom> have a large amount of audio content.
Sam: Just drop first sentence, don't say anything about labor intensive
Not technically feasible at this time.
GreggVan: We can say the same thing for lots of other SCs - there are no automated tools for other things as well
GreggVan: might be helpful to compare with screen readers
Google doc link: https://
<bbailey7> +1 to not feasibly logistically
<bbailey7> Or technically infeasible because the logistics necessary to implement are not possible with current technology?
[multiple edits happening in google doc]
New edits are now in the document as proposal 3
maryjom will send out a survey
Thanks all