Meeting minutes
Announcements
<PhilDay> Link to project board view: https://
PhilDay: Three more questions. We don't have any other drafted content. Please have a look at the status wiki or project list
<PhilDay> Link to level AAA status table on wiki: https://
BBailey: Timezone's changing. Look at that for the next three weeks
… There's two CFCs on AGWG this week
PhilDay: Question on non-web ICT. It's used more than 16 times and I think it's consistent
<PhilDay> Issue on use of non-web ICT: w3c/
GreggVan: non-web documents and software versus non-web documents and non-web software is problematic
… We cna have non-web always or never repeated
PhilDay: I'll create an action to review this
GreggVan: Yes, I think this is editorial
ACTION: Search for use of non-web documents and software vs non-web documents and non-web software - use consistently
BBailey: Agree with consistency. I think non-web ICT is different than that
GreggVan: Should say "includes but is not limited to"
<Zakim> PhilDay, you wanted to ask clarification
<BBailey> non-web ICT includes but is not limited to non-web documents and software
PhilDay: Do we need to make further edits to your proposed updates to intro?
GreggVan: There are instances on the intro, and possibly other places too. We need to make clear that it's a shorthand
ACTION: Define non-web ICT as includes but not limited to non web docs and software
LauraM: What would we be looking for if I were to take an editorial pass at the whole document?
GreggVan: I think it's in the intro where we define non-web ICT, unless we have it on the definitions section
LauraM: Or both
GreggVan: Might be a good idea to put this on the definitions
… Then every place where we use "non-web documents and softwre", it either ought to be always as-is or we should repeat "non-web" for software as well
… These two occurrences may imply we mean something different
LauraM: We mean "non-web documents" and "non-web software". Is that correct?
ACTION: Editorial pass for consistent use of “non-web documents and software” versus "non-web documents and non-web software”
GreggVan: I would ssay "non-web documents and non-web softwware" to unambiguously define these better.
LauraM: It feels ambiguous, even though I feel I know what it means
<LauraM> Yes.
LauraM: I think it's less ambiguous to say "non-web documents and non-web software"
GreggVan: EN 301 549 has it separate
<PhilDay> POLL: Should we use "non-web documents and software" (option 1) or "non-web documents and non-web software" (option 2) throughout the document?
GreggVan: And then there's software that's broader than these two
<BBailey> 2
<LauraM> 2
<GreggVan> 2
<PhilDay> Loic: option 2
2
<PhilDay> DRAFT RESOLUTION: use "non
<PhilDay> DRAFT RESOLUTION: Use "non-web documents and non-web software" consistently throughout to avoid ambiguity
Daniel: Why not shorthand?
GreggVan: Still ambiguous and doesn't follow commonly accepted English meaning
<Daniel> +1
<BBailey> +1
<GreggVan> +1
Loic: +1
<LauraM> +1
RESOLUTION: Use "non-web documents and non-web software" consistently throughout to avoid ambiguity
Laura: I'll take a pass at the whole document to amend this
<BBailey> We could always use parenthesis: non-web (documents and software) /s
Question 4 - 1.2.6 Sign Language (Prerecorded)
<PhilDay> Link to q4: https://
<PhilDay> Link to Google doc with proposals: https://
<PhilDay> Proposal 2: Add 2 notes to address comments – clean – all suggestions accepted
<PhilDay> Applying SC 1.2.6 Sign Language (Prerecorded) to Non-Web Documents and Software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
<PhilDay> Note 1 (Added)
<PhilDay> 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 would not be technically feasible to require for all audio content to have sign language interpretation, especially where non-web documents and software
<PhilDay> have a large amount of audio content.
<PhilDay> [ALTERNATE NOTE 1]
<PhilDay> With current technologies, providing sign language for all synchronized media is labor-intensive. In the absence of reliable automated methods to produce sign language interpretation, it would not be technically feasible to require all audio content to have sign language interpretation.
<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> Then in the SC Problematic for Closed Functionality add the following bullet:
<PhilDay> 1.2.6 Sign Language (Prerecorded) — Where the ICT does not have the ability to provide or attach a display (e.g. an audio-only device), it would not be appropriate to require this success criterion because it would require a fundamental alteration to the ICT’s intended design and usage.
<PhilDay> Proposal 3: Gregg’s proposed language from survey – clean – all suggestions accepted
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
<PhilDay> NOTE 1: Today, there are not enough sign language interpreters world-wide to handle content generated in a single day making it logistically impossible to require for all content. However, emerging technologies will fairly soon allow translation from text or speech to sign language directly - at which time those who want sign language could use
<PhilDay> such a translator in the same way people who are blind use a screen reader. This would give people who need sign language presentation the same or superior access that screen reader users have to all web content. However, until the latter occurs, providing sign language interpretations is immensely helpful for native sign language users -
<PhilDay> especially for any 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> Proposal 4: Taking Daniel’s comments from the survey to adjust Note 1 - clean – all suggestions accepted
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
<PhilDay> Note 1 (Added)
<PhilDay> With current technologies, specialized human intervention is needed to produce high enough quality sign language interpretation that would satisfy this requirement. This causes limitations on the amount of media content that can be provided with sign language interpretation. However, providing sign language interpretation is immensely helpful for
<PhilDay> native sign language users - especially for any 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.
BBailey: I'd want to vote for proposal 4, but survey was closed
<PhilDay> BBailey: wanted to vote for proposal 4.
GreggVan: I think what's missing is that we should clarify that the screen reader is not an author problem. Very soon we'll have the ability for sign language to be added to every page with AI
… There will be a tool that will make it available for all the pages
<PhilDay> scribe:
Daniel: Sounds like we are saying "we could do this through some AI tool in the future" - like screenreaders can. Also not sure if this is close in the future
GreggVan: Screen readers are a solution because we have "programmatically determined"
… For sign language we are saying we need to build a screen reader for every page
… It's nowadays technically not possible
… We should add for wwhen it is automatically possible
… Different people use different kinds of sign languages
PhilDay: I'm hearing arguments for these two proposals, 3 and 4
POLL: which proposal do you prefer, also include which you could also accept? 3 - proposal 3. 4 - proposal 4.
<BBailey> prefer proposal 4, can accept proposal 3
<GreggVan> 3
<loicmn> 3 (with edits as suggested by Daniel, Gregg), then 4
GreggVan: Not possible today, extremely possible before WCAG 3 comes out :-)
4, can accept 3 with subsequent editorial edits
LauraM: I am abstaining
PhilDay: Based on the votes, the only one that is acceptable for everyone is 3
… I would propose we go with 3
GreggVan: Yes, but I'd like to make sure comments from Daniel are addressed
GreggVan: Suggest a minor edit to proposal 3 to address Daniel's comments
<BBailey> Laura's comment from survey: Both options (as is and with Gregg's proposed edit) are fine. I don't feel strongly in either direction.
GreggVan to propose suitable wording.
Daniel: Happy to move forward with this later, will watch for Gregg's proposal
Suggestion is that we go forward with a revised version of proposal 3; GreggVan to issue this revised version.
Question 5 - (Part 1 of 2) 1.3.6 Identify Purpose
Link to q5: https://
Link to Google doc, proposal 3: https://
PhilDay: Most prefer 3 as written. Gregg, you did have some edits
GreggVan: We shouldn't have a note defining something that's in the definition. I suggest we link to the definition
… Then, if I write a letter in HTML, do I have to put headings in the letter?
… Provision is if you have headings, these would need to be accessible
PhilDay: Mary Jo has comments here. Maybe it's related to WCAG itself rather than to WCAG2ICT?
GreggVan: It's helpful, but not required, this is why it's AAA
Proposal 3: Modify the 1.3.6 SC language to not use “region”
Make a suggested change to the SC language to not use “region” and instead use the term “section”.
Applying 1.3.6 Identify Purpose to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.6, replacing “regions” with “sections” because non-web documents and software often do not have a semantic equivalent to a “region” as it is defined by WCAG 2.
With this substitution, it would read:
In content implemented using markup languages, the purpose of user interface components, icons, and sections can be programmatically determined.
Note 1 (Added)
A section may consist of one or more paragraphs and include graphics, tables, lists and sub-sections.
Note 2 (Added)
This success criterion only applies to non-web documents and software that are implemented using markup languages, that support programmatically exposing the purpose of user interface components, icons and sections, and that the user agent or platform software can extract and present that purpose to users using different modalities, as explained in
the Intent from Understanding 1.3.6 Identify Purpose.
GreggVan: I think we need to explain why it's in AAA
<Zakim> loicmn, you wanted to say that 1.3.6 is not requiring sections
Loíc: The SC is not asking to create sections
… IF sections exists, then they need to be programmatically determined
… The letter example would be the letter as a whole section
GreggVan: The definition of section is a paragraph, it could be anything
Daniel: know we have some ambiguity on definition of section - not sure it is as bad as constituting a paragraph
Daniel: I don't think a section is equal to a paragraph
BBailey: The problem is that section and region as used in WCAG 2 have the same meaning
… This has been raised to AG and AG doesn't feel like making any editorial corrections in the short time
GreggVan: It would be helpful to explain why it is on AAA. Everytime we change topics that is a new section
BBailey: They're both underspecified
PhilDay: Most people preferred this prooposal. Which concrete changes would you suggest, Gregg?
https://
<BBailey> From WCAG 2.2: https://
<BBailey> perceivable, programmatically determined section of content
Gregg: Section definition applies it to only markup languages
GreggVan: suggests removal of note 2 from proposal 3
<BBailey> https://
<BBailey> a self-contained portion of **written** content that deals with one or more related topics or thoughts
<BBailey> emphasis added
Gregg: I don't think note 2 should be there
GreggVan: Suggests replacing both notes with new note:
Although helpful to provide headings to better understand the content, it is not required as it is not clear when topics are changing.
<LauraM> @PhilDay been a while since I edited in Github for this, can we schedule a brief call to run through it quickly?
Gregg: The only thing I would do is to replace the two notes with a new one that says that although this is helpful, it's not required because it's not clear when the top things are changing, or when therre's a change of topic, or if people are changing topics, ect
<Zakim> loicmn, you wanted to say the SC talks about markup languages so note 2 is needed
Loic: Note 2 iss taking from other examples of SCs that contain the same "content implemented using markup languages"
… It is not asking for sections to exist, it's asking for the purpose of sections to be programmatically determined
… It's AAA because purpose is difficult to generalize across other technologies
… I still feel that proposal 3 is good enough
GreggVan: I think that 3 is fine without the notes
<BBailey> fwiw I also agree proposal 3 is good enough
POLL: Which would you prefer for 1.3.6? 3 for proposal 3. 4 for Gregg's edit to proposal 3 (replacing 2 notes with something else). 5 for something else
GreggVan: Note 1 shouldn't be defining section, that's normative in WCAG
… If note 2 is repeating what's already on the provisions, we should not be using it
… Some software uses HTML in combination with other technologies
PhilDay: I've put a poll
GreggVan had to leave for another call
LauraM: The morees a re about the definitions, the note 2 is the one that's not substantial
<BBailey> 4 (greggs edit to proposal 3) but 3 is okay
LauraM: Maybe we should separate in the poll
POLL: Which would you prefer for 1.3.6? 3 for proposal 3 with both notes as written. 4 for proposal 3 with note 1 only, 5 for proposal 3 with note 2 only. 6 for proposal 3 with Gregg's new note. 7 for anything else
<BBailey> Just noting that this will come up again when we tackle 2.4.10 https://
<loicmn> 3, then 5
<LauraM> 4
<BBailey> 6 but okay with other choices
3
PhilDay: No consensus on this one, we'll continue next week. Reach to me via email, I'll create a survey to address these concerns
<GreggVan> 6
BBailey: 2.4.10 is one we could do, as it's also related to sections
BBailey: Suggest we look at how we handled 2.4.10 as there is some crossover
<LauraM> Regrets for me next week
<GreggVan> as written without the notes defining section -- or restating that it is html -- but not applying to embeded html in a app where it is not a "document" in form.
Next steps
PhilDay: We will continue with this one next week, then move on to the definition of section/region
… People please take more items on so that we have more drafted content to work on next weeks