Meeting minutes
Announcements
PhilDay: Mary Jo is working through the document, very much appreciated. We've given her another two weeks, review time extends until 2nd October but we're flexible
AG WG review: Review PRs arising from last week
PRs: w3c/
PhilDay: We went through some issues last week. If you want to, you can review the PRs. If you have any concerns let me know
Announcements
AG WG review: Editorial - SC 1.2.6
Issue for tracking:
Proposal at w3c/
PhilDay: Uses of the word translation
NOTE 1 (ADDED)
To date, meeting this success criteria has proven to be infeasible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being produced. As compared to captioning and audio description, sign language interpretation is a very specialized skill. Emerging technologies may, in the
future, allow **interpretation** from text or speech to sign language directly. At that time, those who need sign language could use such an automated **interpretation** tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access this
content that people who are blind have access to by using their screen readers.
As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any public service content.
In https://
1.2.6 Sign Language (Prerecorded) (Level AAA)
Live sign language **interpretation** may not currently be logistically feasible for ICT with closed functionality.
PhilDay: Proposal above, this is fairly easy
bbailey: This is after the wording about sign language?
GreggVan: It says interpretation now
… It should be "sign language interpretation"
bbailey: Except for the sign language context, I wouldn't worry if translation is used somewhere else
GreggVan: What's the difference between translation and interpretation?
DRAFT RESOLUTION: For SC 1.2.6 Sign Language (Prerecorded), incorporate proposal (word change in SC and SC problematic for closed) into the editor’s draft, as is
bbailey: It is about syntax
<Sam> +1
<loicmn> +1
<bbailey> +1
<PhilDay> +1
<Daniel> +1
RESOLUTION: For SC 1.2.6 Sign Language (Prerecorded), incorporate proposal (word change in SC and SC problematic for closed) into the editor’s draft, as is
AG WG review: SC 1.2.7
ISSUE: w3c/
Content:
The guidance could benefit from a note similar to what is provided for SC 1.2.6 because similar limitations exist with having enough professionals and the specialized skills they need to create audio description for all media content. AI also exists, if the quality is high enough, that could automatically provide extended audio description.
<GreggVan> what is the difference between translation and interpretationThe core difference is the medium. Translation works with written text; interpretation works with live spoken or signed language.
<GreggVan> That one distinction drives several others:
<GreggVan> Timing: A translator works asynchronously, with time to research, revise, and polish. An interpreter works in real time, either simultaneously (a few seconds behind the speaker, as at the UN) or consecutively (the speaker pauses and the interpreter renders each chunk).
<GreggVan> Precision vs. immediacy: Translation aims for a finished, accurate, stylistically faithful text. Interpretation aims for faithful meaning delivered immediately, so it relies more on paraphrase, condensing, and judgment calls made on the fly.
<GreggVan> Skills: Translators need strong writing in the target language and good research habits. Interpreters need listening comprehension, short-term memory, split attention, and composure under pressure. Interpreters usually work in both directions; translators often work only into their native language.
<GreggVan> Tools: Translators use CAT tools, glossaries, and translation memory. Interpreters mostly work unaided, apart from prep materials and booth equipment.
<GreggVan> Deliverable: Translation produces a permanent artifact. Interpretation is ephemeral unless someone records it.
Proposed guidance for 1.2.7
Applying SC 1.2.7 Extended Audio Description (Prerecorded) to non-web documents and non-web software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.7.
NOTE 1 (UNCHANGED FROM CURRENT 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.
NOTE 2 (ADDED) (DERIVED FROM NOTE 1 of 1.2.6)
To date, meeting this success criteria has proven to be infeasible, as there are not enough human professionals with the specialized skills needed to create audio description for the volume of video content being produced. Emerging technologies may, in the future, allow automated generation of extended audio description from a video source
directly. At that time, those who need extended audio description could use such an automated interpretation tool in the same way people who are blind use a screen reader. This would give people who need to have extended audio description the same ability to access this content that people who are blind have access to by using their screen readers.
As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the community of extended audio description users. In the meantime, providing extended audio description continues to be a need for some people, especially in the context of any public service content.
bbailey: This is not "liv", so scope is different
PhilDay: Limitation is not really the number of professionals it would just take longer
GreggVan: It's the amount created at once. There is more content generated in a second than interpreters could interpret in one year
bbailey: I disagree, they're able to find enough human resources
<Zakim> loicmn, you wanted to point to 1.2.5 vs 1.2.7 is only extended
loicmn: We already have a AA SC, the only difference is about extended audio description
… I wouldn't like to have this note in a AA SC. If we think it's so infeasible then we should tell WCAG about it
bbailey: It should only apply to sign language. Audio description is not nearly as difficult as sign language
<Zakim> bbailey, you wanted to ask what we say about extended audio description ?
Daniel: It's only upon request that most of these features are actually implemented, so this reduces the scope of this considerably
<bbailey> s/bbailey: it should/Gregg: it should/
bbailey: I'm not comfortable applying it here
Sam: It's still most specialized than others and should be considered an exception
GreggVan: Audio description shouldd be limited to non live
… You cannot describe live in the gaps because you don't know when the gaps are
… It's true that if you do know how to do audio description you can do a much better work
bbailey: For extended audio description we don't caveat that in any way
GreggVan: Because it's a recommendation
bbailey: We should also not caveat sign language prerecorded
GreggVan: It's disruptive to have a movie that stops for the audio description
<Zakim> loicmn, you wanted to say I think we don't need MJ suggested note in 1.2.7 as not the same as sign language
loicmn: I don't think we need the note. It doesn't really make sense. You are using generally the same spoken language
… Difficulty is lower thant it is to interpret
… This is AAA because content-wise creators wouldn't like the audio description to stop the content they are creating
GreggVan: Have we reached consensus to not include the note?
Sam: I disagree that it's easier. It does require specialized training and skills
<bbailey> I apologize for making the comparison to AAA extended audio descriptive as that turned out not to be so constructive
GreggVan: There is a manual that's fairly straightforward
<PhilDay6> POLL: Should we add something like NOTE 2 about feasibility of extended audio description? Answer 1 for Yes, 0 for No.
<loicmn> 0
<Sam> 1
<bbailey> 0
0
<JamesH> 0
<GreggVan> 0
<bbailey> I am okay with a note if it is softened a bit.
<GreggVan> disruption
PhilDay6: Sam, would you be OK with a note that doesn't talk about feasibility?
<loicmn> ISO/IEC TS 20071-21:2015 Information technology — User interface component accessibility - Part 21: Guidance on audio descriptions - https://
Sam: I'll go with consensus
<PhilDay6> POLL: Would you rather have no NOTE 1 at all, or a softened NOTE 2 talking about the challenges of creating audio description? Answer 0 for no note, 1 for softened note
GreggVan: If we have a softer note I would put thingsg about disruptions, not about difficulty
<PhilDay6> extended audio description - requires disruption of the media - pausing
<PhilDay6> DRAFT RESOLUTION: For 1.2.7 Extended Audio Description (Prerecorded), reject proposal for new NOTE, and keep unchanged
<loicmn> +1
<Daniel> +1
<bbailey> +1
<JamesH> +1
<Sam> 0
<PhilDay6> +1
<GreggVan> +1
PhilDay6: Are you OK with this?
RESOLUTION: For 1.2.7 Extended Audio Description (Prerecorded), reject proposal for new NOTE, and keep unchanged
ACTION: PhilDay6 to respond to Mary Jo
Sam: Yes, that's what I think 0 is
AG WG review: SC 1.3.6
ISSUE: w3c/
<PhilDay6> Content:
<PhilDay6> 1.3.6 Identify Purpose is one WCAG SC that is ambiguous altogether. I agree, the definition of "region" with regard to non-web documents and non-web software is not sufficiently clear. The language of the requirement itself, is also unclear. How is this SC different from what is already required by other SC - semantic labels and roles. SC 1.3.5
<PhilDay6> Identify Input Purpose was clear and focused on specific roles for input fields and gave a schema to follow for additional markup. This SC is ambiguous and the way it is written it is unknown what schema(s) to use and what specific items must have a purpose defined that is outside of the already required name, role, value and meaningful labels.
<PhilDay6> Techniques from the Understanding 1.3.6 don't provide the needed clarity either. Do document authoring tools and viewers and non-web software platforms support additional semantics for user interface components, icons, and regions beyond the name, role, value and labels? If not, then this SC might not be able to be met outside of the web.uality is
<PhilDay6> high enough, that could automatically provide extended audio description.
<PhilDay6> Current guidance:
<PhilDay6> Applying SC 1.3.6 Identify Purpose to non-web documents and non-web software
<PhilDay6> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.6.
<PhilDay6> NOTE 1 (ADDED)
<PhilDay6> This success criterion only applies to non-web documents and non-web software that are implemented using markup languages, and that support programmatically exposing the purpose of user interface components, icons and regions.
<PhilDay6> NOTE 2 (ADDED) (FOR NON-WEB SOFTWARE)
<PhilDay6> "Content implemented using markup languages" includes parts of software that use markup internally to define a user interface. Examples of markup languages that are used internally to define a software user interface include but are not limited to: HTML (e.g., in Electron applications or iOS application web views), XAML, XML (e.g., in Android
<PhilDay6> application layouts), and XUL.
<PhilDay6> NOTE 3 (ADDED) (FOR NON-WEB SOFTWARE)
<PhilDay6> 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
<PhilDay6> definition.
<PhilDay6> NOTE 4 (ADDED) (FOR NON-WEB SOFTWARE)
<PhilDay6> For general guidance, see also the comments on closed functionality. For commentary on the individual success criterion, see Success criteria problematic for closed functionality, Identify Purpose.
GreggVan: 1.3.1 talks about the visual purpose should be programmatically determinable
… This is about whether or not the thing is properly label. This is a cognitive-related SC
… Agree that this is a bit vague, like other things
<bbailey> https://
GreggVan: Some people complain about 1.3.1 because "indicated visually" is also ambiguous
PhilDay6: Currently we say applies as written and then we qualify with notes
<PhilDay6> Daniel: Could use "this is problematic to apply" - rather than applies directly as written
Daniel: This is one we could use "this SC is problematic to apply" ...
GreggVan: Unless we think something in AAA should be applied to non-web
… I don't think we should write rationale that should be in WCAG's understanding
… Otherwise we'd have to go back to all AAA SCs to review them from that perspective
bbailey: Mary Jo's comment seems to conflate 1.3.5 and 1.3.1. I don't think we need to make a change
PhilDay6: Are you suggesting Bruce to leave the ED as is?
bbailey: Yes. I agree about saying something about markup languages
GreggVan: Agree
bbailey: Like having NOTE 2
GreggVan: Also like having NOTE 2
GreggVan: +1 to applying to markup
<bbailey> https://
Latest WCAG2ICT: https://
<bbailey> In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined.
GreggVan: There is not a reason to have a note that says what the provision says already
<Zakim> loicmn, you wanted to explain note 1 was about programmatic exposing information
Sam: That's what I think it's helpful to have it, to reinforce the idea that it applies in a markup context
loicmn: In note 1 we provided the context. Then if you have the possibility to programamtically expose information, which is supposed to be doable in the web, that's what it refers to
… Note 3 is opening up to how it could be applied outside of the markup context
… I'll keep the notes as they are
GreggVan: Note 1 and 3 contradict each other
… We shouldn't determine things that do and do not apply
GreggVan: Note 1 could say that WCAG SC only applies it to markup contexts
GreggVan: Note 1 needs to exsist in the context of note 3, so we may want to combine the two
Sam: Note 1 doesn't say should anywhere
GreggVan: The success criteria is about web content
… We are already saying what is in note 1 in the above sentence
… And note 1 still contradicts note 3
<Zakim> PhilDay, you wanted to say NOTE 3 does not contradict NOTE 1
PhilDay: I don't think note 3 contradicts. It says it need not to be limited to markup language
GreggVan: But then we should delete note 1, because it's not adding anything else
POLL: Should we keep 1.3.6 "applies directly as written", or should we soften it "may be problematic to apply"? Answer 0 for keeping as is, 1 for changing to "may be problematic"...
GreggVan: It's not problematic, it would be overly limited
bbailey: We could write "this can be applied directly as written and described" and then continue with our notes
bbailey: Could use "this may be applied directly as written"
GreggVan: +1 to use Bruce's language, and then first note would be currently note 3, then we have our note 2, and note 4 becomes note 3
<Zakim> loicmn, you wanted to say keep applies directly, but modifying note 3 to start as Although not required by this success criterion (like 3.2.3 consistent navigation)
<JamesH> +1 to GreggVan - I think that works
loicmn: In consistent navigation we explained that that only made sense in the sets of documents and non-web software and that if you do something on a single instance it should be good because it meets user needs. We could re-apply that to this context
<PhilDay4> POLL: Are you happy keeping "applies directly as written" but reworking NOTE 3 as per Loic's suggestion? Answer 1 for yes, 0 for no?
<loicmn> 1
1
<bbailey> +1
<JamesH> +1
<Sam> 1
<PhilDay4> 1
<GreggVan> 0
<PhilDay4> GreggVan - is neutral
<loicmn> Summary of my proposal to redraft note 3 following note 2 in 3.2.3
<PhilDay4> DRAFT RESOLUTION: For 1.3.6 Identify Purpose, incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (change NOTE 3)
<loicmn> +1
<bbailey> +1
<Daniel> +1
<JamesH> +1
<PhilDay4> +1
RESOLUTION: For 1.3.6 Identify Purpose, incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (change NOTE 3)
RESOLUTION: For 1.3.6 Identify Purpose, incorporate proposal into the editor’s draft, with edits shown in the meeting minutes above (change NOTE 3)