Meeting minutes
<Daniel> scribe+ Light sccribing today as we're a small group
Announcements
Link to project board view: https://
Link to level AAA status table on wiki: https://
• Daylight saving: US & Canada change to daylight savings on Sunday 8th March. Europe & UK do not until Sunday 29th March
For those in Europe, meeting is 1 hour before
<Sam> going to CSUN next week
<Daniel> scribe+ Time shift -- For us in Europe and UK the meeting will be an hour before for the next three weeks
loicmn: cannot make meetings until Europe moves to daylight savings
ACTION: PhilDay to cancel next week's meeting
Canceling next week's meeting due to CSUN
Editorial – non-web documents and non-web software
PR on this: w3c/
<Daniel> acck me
Daniel: Problem with doing this separately - we just need to modify the anchors after content has changed
Question 4 - 1.2.6 Sign Language (Prerecorded)
Link to q4: https://
Link to Google doc with proposals: https://
Discussion last week – proposals 3 & 4 were preferred, with 3 being the only one that everyone would accept
GreggVan: getting extra emails so may not see messages from GitHub. Send email directly to him for contact
Proposal 3: Gregg’s proposed language from survey – clean – all suggestions accepted
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
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
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 -
especially for any public service content.
Note 2 (Added)
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..
Note 3 (Added) (for non-web software)
See also the Comments on Closed Functionality.
Proposal 4: Taking Daniel’s comments from the survey to adjust Note 1 - clean – all suggestions accepted
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
Note 1 (Added)
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
native sign language users - especially for any public service content.
Note 2 (Added)
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.
Note 3 (Added) (for non-web software)
See also the Comments on Closed Functionality.
Daniel: concern that note built on the premise that there will be tech in the future that can automatically translate.
… Had concerns that we cannot be certain that it will happen. We could say "if there is technology in the future, ...."
GreggVan: Still believes AI technology will be ready for sign language interpretation.
GreggVan: Has slightly modified proposal 3 to address Daniel's concerns
ACTION: PhilDay to circulate how to copy & paste clean version from Google docs
Revised version of proposal 3:
Proposal 3: Gregg’s proposed language from survey
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6.
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
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 -
especially for any public service content. As always, authors should not rely on this until it is commonly available at a quality accepted by the signing community.
Note 2 (Added)
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..
Note 3 (Added) (for non-web software)
See also the Comments on Closed Functionality.
• POLL: Which do you prefer? 1) Proposal 3, as-is; 2) Proposal 3, with latest edits; 3) Proposal 4, as-is; 4) Something else.
POLL: Which do you prefer? 1) Proposal 3, as-is; 2) Proposal 3, with latest edits; 3) Proposal 4, as-is; 4) Something else.
<loicmn> 2
<GreggVan> 2
Daniel: more editorial work needed -basic premise is good, but it needs polishing
<Daniel> Daniel: OK but needs editorial changes
GreggVan: suggest we accept if all are happy with the premise - and then editors can tweak the language.
Daniel: would accept
DRAFT RESOLUTION: accept edited proposal 3 above, with editors to make further editorial improvements as they see fit
<loicmn> +1
<Daniel> +1
<GreggVan> +1
RESOLUTION: accept edited proposal 3 above, with editors to make further editorial improvements as they see fit
ACTION: PhilDay to create PR based on this, and assign Gregg and Daniel as reviewers
Question 5 - (Part 1 of 2) 1.3.6 Identify Purpose
Link to q5: https://
Link to Google doc, proposal 3: https://
• Majority preferred proposal 3. There was some discussion last week about taking proposal 3 but removing or modifying one or both notes, but no consensus was reached.
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.
Changes to definitions sections
“Section” is defined in WCAG 2.2 as:
section
a self-contained portion of written content that deals with one or more related topics or thoughts
In the Comments on Definitions in WCAG 2 Glossary section, make the following changes:
Remove “region” from the WCAG2ICT section Glossary Items Used only in AAA Success Criteria. This term will only be mentioned in WCAG2ICT in the word replacement language in the guidance for SC 1.3.6, not in the glossary sections.
Move “section” from the Glossary Items Used only in AAA Success Criteria section to the WCAG2ICT section Glossary Items that Apply to All Technologies.
Proposal 3: Modify the 1.3.6 SC language to not use “region” (just body text)
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.
GreggVan: Suggests sections should be "visually identifiable sections"
GreggVan: Would like to remove this recommendation entirely from WCAG
GreggVan: Not agree that sections is better than regions
<Zakim> loicmn, you wanted to say we it might be better to come back to region
loicmn: Think that we might be better using region, and then finesse the definition of region so it works outside the web domain
… problem was that notes for region had examples that were specific to HTML
GreggVan: "self-contained portion" is undefined
POLL: Which do you prefer in the body of the 1.3.6? 1) Region; 2) Section; 3) Something else
<Zakim> loicmn, you wanted to say that we might go to the HTML definition of section
<loicmn> "A section, in this context, is a thematic grouping of content, typically with a heading."
loicmn: what WCAG defines as a region, is similar to the HTML definition of a section.
<loicmn> https://
loicmn: Seems to be an underlying problem with WCAG, but we may be able to use the words from HTML section definition to help us define a region.
Daniel: Bruce commented that the change we requested on WCAG has been submitted - but it is a long way from happening. We already proposed a change to this wording. Going back again on this would be problematic.
<Daniel> Bruce comment to note that WCAG 2 backlog approved changing the term
POLL: Which term do you prefer to use in the body of 1.3.6? 1) Region; 2) Section; 3) Something else
<Sam> 2
Sam: Are we trying to fix WCAG? Suggest we should not try and fix that.
GreggVan: agree with Sam. We are not here to fix WCAG.
… maybe better to not try and fix something that is broken
changing region to section may not help.
PhilDay: Suggest we leave as is (with region), then add a note about non-web documents and non-web software
GreggVan: Add a comment that if it is important, it may need to apply more widely than just to markup languages.
Proposal: Leave text using "region", and then just add a note to comment on non-web context. Do you agree with this?
<Sam> +1
<loicmn> +1
<GreggVan> +1
<Daniel> +1
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.
<Sam> This success criterion only applies to all non-web documents and software, 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
<GreggVan> NOTE: The WCAG2ICT working group notes that the term region is not objectively defined enough to be a requirement rather than a recommendation.
<GreggVan> Also as a recommendation it is not clear why it is limited to markup langauages
Proposal 4: Revert to region, add note to give non-web context
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,.
In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined.
NOTE 1:
This success criterion only applies to all non-web documents and software, 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.
<Zakim> loicmn, you wanted to say yes to Sam but refer to best practice
loicmn: We cannot remove markup language from the SC. The only thing we can do is add a note that it only applies in these cases.
Then add another note to say if it is not a markup language but the rest applies then you should do this as best practice
Sam: thought it was OK to remove from the note - just not in the SC itself
<GreggVan> The WCAG2ICT working group also notes that as a Level AAA provision which is essentially a recommendation, this need not be limited to markup languages. If being considered for a requirement then the term "section" (or region if that was considered as a substitute) would need to have an objective definition rather than its current ambiguous definition.
loicmn: Adding a 2nd note that talks about best practice - although not required if there is no markup language, if all other parameters exist, it is best practice to provide the ability to identify purpose
GreggVan: Applies as written, substituting web... with non-web documents and non-web software.
<Sam> +1 to Gregg
<loicmn> +1
<PhilDay> +1 from Daniel
<GreggVan> +1
<Daniel> +1
Proposal 4: Revert to region, add note to give non-web context
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,.
In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined.
NOTE 1 (GREGG)
The WCAG2ICT working group also notes that as a Level AAA provision which is essentially a recommendation, this need not be limited to markup languages. If being considered for a requirement then the term "section" (or region if that was considered as a substitute) would need to have an objective definition rather than its current ambiguous
definition.
ACTION: PhilDay to add relevant word substitution to SC 1.3.6 body text.
DRAFT RESOLUTION: For 1.3.6 Identify Purpose, use edited version of proposal 4 above with new NOTE 1
<loicmn> +1
<Sam> +1
<GreggVan> +1
RESOLUTION: For 1.3.6 Identify Purpose, use edited version of proposal 4 above with new NOTE 1
<GreggVan> preent+