W3C home > Mailing lists > Public > public-html@w3.org > April 2010

RE: Change Proposals toward Issue-9: "how accessibility works for <video> is unclear"

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Mon, 12 Apr 2010 11:03:05 +0000
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: public-html <public-html@w3.org>
Message-ID: <8DEFC0D8B72E054E97DC307774FE4B911A4EAC4C@DB3EX14MBXC303.europe.corp.microsoft.com>
Well quoting from the description of @title "The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource"
-- seems right to me.

In marker mode there is no guarantee that timecodes are continuous or in any specific order, thus a time could be 'between' the start and end, but not trigger the end semantics.

"audio description" would be fine.

-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: Monday, April 12, 2010 1:30 AM
To: Sean Hayes
Cc: public-html
Subject: Re: Change Proposals toward Issue-9: "how accessibility works for <video> is unclear"

Hi Sean,

On Sun, Apr 11, 2010 at 11:21 PM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> A few quick comments on the second proposal. (This deals only with the markup section, I'm also working on a more detailed discussion for the rendering section).
> @name probably ought to be @title - this seems to be closer to the usage of @title on other elements.

The choice of @name is on purpose to avoid clashing with @title, since @title is already a standard attribute of HTML elements and has its existing meaning. Here, we chose @name to expose a given identifier for a track inside multitrack media files or provide an identifier for external tracks. Consistency across the API made us chose this attribute name also for the <track> element.

> You need to mention how the <trackgroup> and <track> elements fit into the content model of the <video> and <audio> element, it's not clear that multiple <trackgroups> for example are legal.

You're right - the details for the <track> and <trackgroup> specifications have not fully been stated - only the DOM interface was provided. But it should be relatively trivial for the editor to add that boilerplate when adding it to the specification. What should be mentioned is:
* content model for <track> is non-empty on purpose, since when we introduce the use of <track> for external media resources, we will again need <source> inside it
* an arbitrary number of <track> or <trackgroup> elements are allowed inside <audio> or <video>

> I would prefix the phrase: "The text in a text interval is displayed while the active resource's currentTime is between the start time of the interval but has not yet reached the end time of the interval (a semi-open interval: [start,end) )."
> With "Unless the text resource semantics define otherwise,"  since for SMPTE marker time mode in TTML the above is not strictly accurate.

I've checked the TTML specification and I don't see it conflicting with the above statement for SMPTE. Even where SMPTE are markers, reaching the "end" marker means it "causes the temporal interval to end". So, I don't see there being a conflict.

> I'd prefer textaudiodesc to just be description.

In MPEG-7 there was something called "scene description", which was text that described the scene. If we were just going for this, I wouldn't mind the name "description". But this role is particularly chosen for accessibility needs to signify a textual description of the scene to be rendered for the vision-impaired most often as audio through a screen reader - potentially also as braille.

"Audio descriptions" are such text read out by a human and recorded, so the name was chosen to stay as closely as possible to that well understood term in accessibility and just add that it's provided as text.

> I'm not sure what "chapters" are in this role list; I suggest they be dropped for the moment.

They are like titles for a segment of time - think of them like DVD chapters. I have a demo of using them at http://annodex.net/~silvia/itext/elephant_no_skin_v2.html (might need to use Firefox to see it) - note them appearing on top of the video.
But I am not too fussed about dropping them off for the moment.

> And you might want to merge the lyrics and karaoke class unless there is some essential difference I'm missing.

Their rendering is different, since the formatting of karaoke will be more specific - progressive colouring, specific placement etc. Their role is probably different, since you could mark up a song with both, lyrics and karaoke - the first targeted at people that just want to read the words while listening to the song, the second at singing along. It's a minor difference though.

> Replace the wording of:
> "If provided, the @enabled attribute specifies that the track is enabled and should be displayed in an appropriate manner. If the attribute is not provided, the track is not displayed."
> With
> "If provided, the @enabled attribute specifies that the track is enabled and is available to be displayed in an appropriate manner. If the attribute is not provided, the track is not available to be displayed  unless the track is enabled dynamically."

The API will set the attribute in the DOM, so that last bit about "unless the track is enabled dynamically" should not be necessary. I'm ok with the rest of the wording.

Received on Monday, 12 April 2010 11:04:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:01 UTC