Meeting minutes
Announcements
Numbers may be low this week - some people are already travelling to TPAC
Call for consensus ends this evening (5 pm Eastern)
All responses have been positive thus far. 1 comment from Bruce (editorial) which we will cover later in this meeting
Issue 527 - worked on it last week (3 finger zoom - is it AT)? There was a lot of chatter after our response.
We may need to make adjustments to our answer - please review the latest conversation when you have time prior to next week.
bbailey transferred this issue to WCAG2
<Zakim> Phil_Day, you wanted to ask for moved link to be added to minutes
<maryjom> Original issue link: w3c/
Moved link: w3c/
PR #810 - [Editorial] Note on 1.23 audio description is poor
<bbailey> Now: w3c/
<maryjom> Link to PR 810: https://
PR 810: w3c/
Bruce thought that the note could be improved by editing a phrase slightly
New version: Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") describe important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be
needed at all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio-video media.
Any objections?
Daniel: Did put a comment - reiterated. New version takes Daniel's suggestion into account
That PR will be merged -it is just editorial
Level AAA Criteria
<maryjom> Link to issue 791: w3c/
Link 791 is a 'master' issue containing links to all AAA issues along with initial discussion.
Suggestion is for people to work through issues in turn, add thumbs up, or indicate if it needs discussion
<bbailey> i have not reviewed
Announcements
Question: TPAC is next week. Should we continue and have a meeting next week? Daniel is going. Is anyone else going?
bbailey: Considering remote sessions - so may attend some
bbailey: Suggest we skip next week and use the time to do a first pass on AAA issues
Level AAA Criteria
Announcements
No meeting next week.
20th Nov we will be meeting
27th is US Thanksgiving holiday - no meeting that day
Then we get into December - how many can we have? 4th and 11th?
December - will only be meeting on 4th and 11th December
Nov 13, December 4 and December 11th will be the only 3 meetings for the remainder of this year
Level AAA Criteria
1.2.6 Sign Language (Prerecorded) (Level AAA)
<maryjom> Link to issue 532: w3c/
[maryjom sharing screen, opening issue 532]
maryjom: Don't think it needs any notes
bbailey: Synchronised media could imply a time aspect, but no visual aspect. So it could be audio in a game - this would be a fundamental alteration.
bbailey: Same problem with audio-only media - now needing captioning
Definition: https://
If media is audio only with timing - could be problematic for closed systems
bbailey to add to the comments for this issue
May be specific to closed functionality - if you don't have a visual output to your ICT, then you can't provide sign language
This should only apply to technologies that have video capabilities.
loicmn: If synchronised media allows for no visual display - then the problem is with WCAG - and needs to be fixed there
… The current definition of synchronised media may need to be updated to avoid this problem (that audio with timings would count as synchronised media).
loicmn: WCAG has audio only and video only portions - which suggests this is a very specific limitation.
… Agree that a note could be added to WCAG2ICT, but suggest WCAG definition is also updated
bbailey: Agree that this is a problem for WCAG so we could just return it back to them.
… But deliberately came up with the phrase synchronised media so it was not just audiovisual together.
bbailey: Suggest we fix it in WCAG2ICT, then open the issue on WCAG2 once we have decided what we want to do
Phil: There could be an avatar that provides sign language
<bbailey> +1 that WCAG “live” problematic because of a realtime game is prerecorded.
Phil_Day: Briefly mentioned that Canada SST standard goes further -and asks for sign language to also be added to live streams / generative content
… But this is technically extremely difficult - and may not be possible with some ICT.
bbailey: Games - similar problem - is this prerecorded, or is it live? We need to consider both situations
bbailey happy to be assigned to this issue - and will draft some content to address this concern
<Zakim> bbailey, you wanted to ask about 1.2.13
bbailey: wanted to comment on 1.2.13 (content on hover) but didn't see it in the master list
bbailey: is 1.4.13
maryjom: This is AA so already done.
bbailey: Noticed that the language in this one is slightly different - the Exception
Current language:
Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.
<bbailey> w3c/
bbailey: suggest we use a different word to "controlled" for consistency. Issue above has been raised on WCAG.
bbailey thought it was AAA so raised it now.
maryjom: If WCAG change it we will need to update WCAG2ICT once the errata has been approved.
1.2.7 Extended Audio Description (Prerecorded) (Level AAA)
Link to issue 533: w3c/
Original proposal had notes 1 & 2. On related audio description SCs we had combined the 2 notes into a single larger note. Proposal from maryjom is to use the latest note that was proposed in the PR mentioned earlier in this meeting.
Current content: 1.2.7 Extended Audio Description (Prerecorded)
(Level AAA)
Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media.
Applying SC 1.2.7 Extended Audio Description (Prerecorded) to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.7.
Note 1 (ADDED)
The WCAG 2 definition of “audio description” says that “audio description” is “also called ‘video description’ and ‘descriptive narration’”.
Note 2 (ADDED)
Secondary or alternate audio tracks are commonly used for this purpose.
Mary Jo's suggested change:
we should use the note that is now on the other two audio description SCs as-is on this one instead of the Notes 1 and 2 proposed in the issue description.
The updated text for the single added note should be:
Audio descriptions (also called "video descriptions", "descriptive narration", and "described videos") describe important visual information needed to understand the video content, including text displayed in the video. Where the main audio track of the video fully describes important visual information, audio descriptions would not be needed at
all as the requirement would already be met. When audio descriptions are needed, one way to implement them is by providing a second audio track for the audio-video media.
<Phil_Day> +1 to use revised note
DRAFT RESOLUTION: For 1.2.7, incorporate proposed text in the issue, replacing notes 1 and 2 with the note above
<Phil_Day> +1
<bbailey> +1
<loicmn> +1
<Daniel> +1
RESOLUTION: For 1.2.7, incorporate proposed text in the issue, replacing notes 1 and 2 with the note above
1.2.8 Media Alternative (Prerecorded) (Level AAA)
Link to issue 534: w3c/
maryjom: Language for the failure technique is incorrect in WCAG - maryjom has raised an issue on WCAG on this problem.
maryjom: We should add a note, pulling in content from understanding to help clarify the language
… Think it will also be problematic for closed - as there is an implicit need for certain types of AT (e.g. Braille display) - which in turn requires a method to connect such 3rd party devices.
<Zakim> Phil_Day, you wanted to comment on closed functionality
<bbailey> +1 for concern
phil: Didn't think about the types of AT you'd have to add to meet this.
… any other synchronized media that you have on-screen would have to be replicated in another or multiple form for closed functionality.
… we don't want to require a screenplay if something is available in multiple formats.
This is a little more complex issue to consider.
<Zakim> bbailey, you wanted to discuss a more global issue with AAA
bbailey More global issue with AAA - they don't apply to all technologies. But we are trying to write something that applies to all tech.
bbailey: WCAG actually says that we should not apply AAA everywhere
… AAA issues already do not apply to all web technologies.
maryjom: We could point out that it is problematic to apply to all technologies.
bbailey: Propose we add a section on AAA to highlight that these do not all apply to all technologies - so it is clear in WCAG2ICT
<loicmn> +1 to Bruce's suggestion to add a "general explanation on AAA". I was thinking the same.
1.2.9 Audio-only (Live) (Level AAA)
Link to issue 535: w3c/
<bbailey> From WCAG Conformance note: https://
<bbailey> It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
Proposal is that this would apply as written
May need some note about closed functionality (similar to 1.2.8) - so could use a similar approach when we have solved 1.2.8
maryjom: 1.2.3 also has related content
(closed functionality note in 1.2.3 - may be useful in 1.2.8)
1.2.9 Audio-only (Live) (Level AAA)
Link to issue 535: w3c/
1.3.6 Identify Purpose (Level AAA)
maryjom: Think this may be difficult to apply to other markup languages - need some platform capability similar to a DOM to allow this level of control. So we could just say that this is problematic.
<Zakim> loicmn, you wanted to suggest starting with what is done for 1.3.5
loicmn: suggest starting with what is done for 1.3.5
Then add more detail
Whatever we wrote for 1.3.5 is a good starting point to 1.3.6
<bbailey> +1 to Loic -- and its worse than that, since we don’t have “Input Purposes for user interface components section”
Content on 1.3.5 from editor's note
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.5.
NOTE 1 (ADDED)
Non-web software and non-web document technologies that do not provide attributes that support identifying the expected meaning for the form input data are not in scope for this success criterion.
NOTE 2 (ADDED)
For non-web software and non-web documents that present input fields, the terms for the input purposes would be the equivalent terms to those listed in the WCAG 2 section Input Purposes for User Interface Components that are supported by the technology used.
NOTE 3 (ADDED) (FOR NON-WEB SOFTWARE)
See also the Comments on Closed Functionality.
loicmn agreed to work on this issue
This week - work on your proposals, then if you have time look at the next few SCs so we have plenty to discuss in 2 weeks time
If you get a proposal done before then - let maryjom know to add to the agenda for discussion