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

> The choice of @name is on purpose to avoid clashing with @title,

That is a fine reason but @name is already used in other markup for 
embedded content. Existing use of @name seems more associated with and 
used more like @id since it seems to be moving towards associating 
with some sort of context identification. Anyway, I would say that 
@name is already taken for I would consider a different purpose.

> Here, we chose @name to expose a given identifier for a track inside 
> multitrack media files or provide an identifier for external tracks.

For "inside" tracks this might be a simple string; Is @trackname 
taken?
probably "external" track (s?) might be a uri? so should have its own 
attribute?

In fact, why not include the @name attr in <video> and <audio> since 
@name in other elements is associated with access by host DOM scripts?

> Consistency across the API made us chose this attribute name also 
> for the <track> element.

Sorry if this is a late comment, but please let's look for consistency 
across the api for all elements, especially, in this case, other 
embedded elements

Thanks and Best Regards,
Joe
.
----- Original Message ----- 
From: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
To: "Sean Hayes" <Sean.Hayes@microsoft.com>
Cc: "public-html" <public-html@w3.org>
Sent: Sunday, April 11, 2010 5:30 PM
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.


Cheers,
Silvia.

Received on Monday, 12 April 2010 02:56:38 UTC