HTML Accessibility Task Force Media Sub Group Teleconference

<trackbot> Date: 14 July 2014

<MarkS> Meeting: HTML Accessibility Task Force Media Sub-Group

Identify Scribe

<scribe> scribe: janina

TTML Issue 309 Text equivalent for caption images

<MarkS> http://www.w3.org/AudioVideo/TT/tracker/issues/309

ms: Our TTML guests are here to get our opinion on resolving this issue

n: variant 1: allows text to be specified purely as text
... variant 2: refs to images
... In reviewing this, though it would fail wcag
... issue is alternative text
... another solution under discussion is to allow some kind of alt against each image

p: to continue the background ...

p: ttml includes spec to deliver subtitle and captions, world wide

p: includes industry participation, movies, tv

p: The above "variants" are subprofiles of the above

p: there are reasons why images are necessary sometimes

p: sometimes artistic reasons, but also lack of gliphs in some langs

jf: These are images loaded as against timeline?

p: yes

p: e.g. embeddeed in mp4 multiplex

jf: mostly for foreign lang?

P: in practice charsets that are not in unicode yet, but also some artistic reasons, iconography, ringing telephone,

<JF> zakim: John_Foliot is JF

JS: we are already at some level in an edge case. Looking to provide alt seems like its more than necessary. the point is to cover everyones needs, not necessarily all in the same technology. if we have a transcript, we probably don't need alt for images in captions.
...its already possible to cover all the needs we are talking about here, just using different tech.

JF: much of this could be solved using metadata, like that specified on schema.org
...if you have document with time-stamping that references images, as long as you have the same content available in another format, we should be OK

jf: agreeing to analysis based on supporting users, using metadata to enumerate available alternatives

p: as with lang

jf: yes

<Zakim> nigel, you wanted to ask if we need to permit all needs to be covered in a single document or if it is okay to permit content providers to meet some needs by providing an alternate

n: wonders about use case where captions are used for tts

<JF> more info about Schema.org+Accessibility: http://www.a11ymetadata.org/the-specification/

n: more fundamental q, from spec perspective, is it necessary to provide capibility for nonimage representation of text as opposed to multiple docs in a wider system
... restating .. we have no option for including text representation for images, as things stand
... at the moment no way to do that
... current alternative is an entirely other document

jf: noting there are also reg issues in some countries
... reality is that as long as both are provided, there's no req that it's all in one doc
... don't say a must, or even a should here ... if tech for achieving the alt is worked out, still a may

JS: we would like to see a programmatic association.

JF: we should think about this as just another language file

jf: the lang analogy is the correct way to thing about this

p: notes there are practices in industry on this

jf: problem is more authoring and best practices

JS: I don't think regulators will be worried about how its done, just that its done.

jf: also mindful of reg reqs

js: but regulators won't care how the coverage is achieved, just that it is

n: not convinced that metadata does exist
... hearing that it isn't a req that the spec provide alt for the caption images, that alternative doc is ok
... think our q is answered ...
... not sure the mechanics exist in mse

p: they do

n: fantastic

jf: would be good to have a best practices doc showing how to do these things

n: thinking about the lang analogy ...
... if it's visual only because gliphs are missing, then a text equiv isn't exactly an equiv

p: you provide descriptive text ... "ringing telephone"

jf: heard more descriptive gliphs, not charset gliphs

p: there's both

n: xml lang not sufficient ...

p: but there are ways, in html5, for instance

Edits to Media Accessibility User Requirements

ms: we believe we're now caught up

<MarkS> https://github.com/w3c/pfwg/commits/master

<MarkS> https://www.w3.org/WAI/PF/HTML/wiki/MAUR_Comment_Processing#DRAFT_Comment_Responses

sm: update on 390 and 391 ...-- actually only 390

<MarkS> http://lists.w3.org/Archives/Public/w3c-wai-eo/2011OctDec/0019.html

sm: basically, content is too complicated, doc written for people with advanced degrees
... our target doc is not ordinary end users

JS: I think we made it clear to EO that we want clear, specific change requests
...we have asked for feedback from them on Section 2, describing people, not the technology
...known all along that is a sensitive area of the document and we want to get the language right there.
...they will look at this heartbeat to address that
...I found a couple of edits, like ref to UA instead of User Agent
...some of the technical engineering language might be considered as such, but its appropriate for the audience

jf: Feel shar's comments are ok, but this wasn't expected to be a "good read," it's a technical document
... if eo feels the need for a more readable document, this is not that document

JS: they have done some good work on such writing in the past. let them do that

[general greement on the response -- this is not the marketing/explanatory end user doc, it's a tech doc]

ms: I worked on the low vis comments, and think I've tweked what is reasonable to tweak
... I tried to avoid repetition. most of the use cases raised could be addresed in transcripts alone.

<MarkS> https://w3c.github.io/pfwg/media-accessibility-reqs/#transcripts

<Zakim> McCarron, you wanted to ask for a clarification on t-3

sm: q in t-3 ... comma after letter, or not?

ms: struggled over that!

<scribe> ACTION: jf to revisit whether to require transcripts be html5 [recorded in http://www.w3.org/2014/07/14-html-a11y-media-minutes.html#action01]

<trackbot> Created ACTION-276 - Revisit whether to require transcripts be html5 [on John Foliot - due 2014-07-21].

JS: some would like to sign off on this heartbeat
...there is some sense that because it is a PF publication, it should be approved by PF.
...happy to do that with a CC to the HTML TF list
...that would expire end of day on wednesday
...Mark could publish on Thursday

[group agreement for 48-hour consensus in pf, with cc to tf]

agreement to publish thursday, pending the pf CfC

Media Accessibility User Requirements Comment Responses

ms: ah, we're done!

<MarkS> https://w3c.github.io/pfwg/media-accessibility-reqs/

<Zakim> kaz_, you wanted to ask janina_ and MarkS if it's OK to talk about TV related topics a bit at the end of this call

<kaz_> tv minutes

KAZ: TV Group is reviewing regenerated use cases, we started with non-accessibility UCs. Web and TV IG is interested in a F2F at TPAC this fall

JS: I think we can arrange that. We should look at schedules and who we would like in those meetings.
...this will take some coordination

KAZ: TV is meeting on Monday, but we can make some arrangement

<MarkS> [adjourned]