- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 06 Jul 2011 13:50:43 +0200
- To: public-html@w3.org
On Wed, 06 Jul 2011 12:47:35 +0200, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Wed, Jul 6, 2011 at 6:33 PM, Philip Jägenstedt <philipj@opera.com> > wrote: >> On Fri, 01 Jul 2011 16:29:23 +0200, Silvia Pfeiffer >> <silviapfeiffer1@gmail.com> wrote: >> >>> Hi Paul, all, >>> >>> after analyzing this problem thoroughly, which I have documented [1], >>> I have come to the conclusion that there is no need for introduction >>> of any normative text into the specification to satisfy this use case. >>> >>> Right now, we have a linear navigation means through text tracks of >>> kind chapter. >>> >>> IMO the best means to provide hierarchical navigation, which is >>> particularly useful to vision-impaired users, is to make it possible >>> to provide navigation lists inside the cues that make up >>> kind="chapters" track. As such cues are handed to AT, their markup is >>> interpreted and made available to AT, including any associated lists. >>> >>> My only suggestion would be to potentially add a recommendation to the >>> specification underneath where "chapters" are introduced [2] >>> which essentially states that subnaviation within chapter cues should >>> be provided through list elements (ul,li) inside a chapter's cue. >> >> There are no list elements in WebVTT, are you suggesting they be added? > > Yes, am. If you look at the examples, I added a <nav> element and am > using the <time> elements as list elements, since the time markers > provide the navigation points. Oops, I didn't notice you'd linked to http://www.w3.org/WAI/PF/HTML/wiki/Media_Navigation until now. >> To >> provide a chapter tree, would it not be better to have dedicated syntax >> for >> it? Perhaps: >> >> 00:00.000 --> 01:00.000 >> 1. Foo >> >> 00:00.000 --> 00:30.000 >> 1.1. Foo, Part 1 >> >> 00:30.000 --> 01:00.000 >> 1.2. Foo, Part 2 >> >> The spec would need to add some parsing for kind=chapters, to deduce the >> level of nesting from the leading x.y.z... > > I've considered this, but with this kind of markup you cannot > guarantee that the sublevels are temporally within the main level and > you have to deconstruct the hierarchy. I think parsing something like > this into a navigation tree is much harder. > > Also, navigation currently works in accessibility technology very > easily through lists, so if we can map whatever we do in WebVTT into a > list markup, that makes it simple. Therefore, I came up with the list > markup as given in the wiki page: > > <ul> > <li><? target='timestamp' data='00:00:03.450'>Subchapter 1</li> > <li><? target='timestamp' data='00:00:04.000'>Subchapter 2</li> > <ul> > <li><? target='timestamp' data='00:00:04.000'>Paragraph 1</li> > <li><? target='timestamp' data='00:00:04.500'>Paragraph 2</li> > <li><? target='timestamp' data='00:00:05.000'>Paragraph 3</li> > </li> > <li><? target='timestamp' data='00:00:06.000'>Subchapter 3</li> > </ul> > > That is using the mapped timestamps from WebVTT to provide the > navigation points and the list markup to allow making use of > screenreaders' hierarchical navigation capabilities. OK, so the idea is that markup as in http://www.w3.org/WAI/PF/HTML/wiki/Media_Navigation#Possible_Markup_for_WebVTT should get converted into a list for getCueAsHTML? That seems a bit funky, how about just letting it be a HTML <nav> element? The syntax here doesn't seem very important though, so let's discuss that when the times actually comes to include this in the spec. >> I'm not convinced this should be added to the spec right away, > > Are we talking about adding something to the WebVTT spec or the HTML > spec? > > For HTML, we don't have to add anything, because IIUC the above markup > (with <ul> etc) would already be supported. We might add an example, > if/when we think this is the right way forward. I don't understand, HTML doesn't seem involved here except for getCueAsHTML, right? > For WebVTT I am expecting a discussion in the WHATWG, since it's not > specified in this WG. There is bugs that track this, see > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12662 . OK, thanks. -- Philip Jägenstedt Core Developer Opera Software
Received on Wednesday, 6 July 2011 11:51:16 UTC