401
edits
Accessibility/Experiment1 feedback: Difference between revisions
Jump to navigation
Jump to search
Accessibility/Experiment1 feedback (view source)
Revision as of 04:32, 5 October 2009
, 5 October 2009added replies to many issues
(added oggkoggk feedback) |
(added replies to many issues) |
||
| Line 113: | Line 113: | ||
::: SP reply: I suppose, similar to [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021125.html Ian's proposal for extending srt to support karaoke and lyrics], it could also be extended with functions for onenter and onleave. | ::: SP reply: I suppose, similar to [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021125.html Ian's proposal for extending srt to support karaoke and lyrics], it could also be extended with functions for onenter and onleave. | ||
::: PJ: Then, the delay method would become somewhat redundant, better to handle this by rewriting the times via DOM (also allows fixing drift, not just constant delay) currentText also wouldn't be needed. | |||
::: SP reply: that forces everyone who has a problem with the start time (and the drift) to write the function to fix it themselves | |||
::: FS: I'd suggest adding another synchronization parameter on top of the "delay". It could be called "stretch". Sometimes different video encodings lead to slightly different playback speed (maybe due to issues related to different framerates). So, one would not only delay the subtitles but maybe also time-stretch it a bit in order to synchronize it. Default value for this parameter would be "100%". If one needs the subtitles to be displayed 3% faster, then he/she would explicitly set stretch="103%". The itext tag (specially if it provides both delay and stretch attributes) will make it easier to implement a clean version of the collaborative subtitling system. | |||
::: SP reply: yes, I like this idea. | |||
* PJ: I think that the fetch and error mechanism might be overkill, how about letting the UA decide if/when to download the resources? You might still want a fetched property I guess, but we might reuse the [http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#dom-img-complete complete property and onload event from the img element]. | * PJ: I think that the fetch and error mechanism might be overkill, how about letting the UA decide if/when to download the resources? You might still want a fetched property I guess, but we might reuse the [http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#dom-img-complete complete property and onload event from the img element]. | ||
::: SP reply: the fetch() function allows the UA to decide when to download the resource. Not sure how else to achieve that. | |||
* PJ: Making enabled writable would remove the need for enable()/disable(). | * PJ: Making enabled writable would remove the need for enable()/disable(). | ||
::: SP reply: I am considering moving it to the itextlist. | |||
* PJ: Depending on the user agents preferred language setting has failed miserable so far - most users just leave it as the default. Sites are forced to use explicit language selection or guess the language based on IP, I expect it would be no different for this feature. I honestly don't know what a good solution for this is. | * PJ: Depending on the user agents preferred language setting has failed miserable so far - most users just leave it as the default. Sites are forced to use explicit language selection or guess the language based on IP, I expect it would be no different for this feature. I honestly don't know what a good solution for this is. | ||
| Line 145: | Line 155: | ||
* RE: It seems to be impossible to listen to the audiodescription and use the other controls using JAWS. | * RE: It seems to be impossible to listen to the audiodescription and use the other controls using JAWS. | ||
::: SP reply: I hope that will be just a temporal issue while ARIA live regions are still new. | |||
* RE: About keyboard tabbing, there is the interesting solution of the US Congress Video archive. Using Tab key you can navigate the temporized transcription and activate the movie at the point you want with Enter key, so I think that using this technique it may be possible to build a secondary console accessible without mouse: http://www.webmultimediale.org/videoblog/2009/07/html5_nello_us_congress_video.html | * RE: About keyboard tabbing, there is the interesting solution of the US Congress Video archive. Using Tab key you can navigate the temporized transcription and activate the movie at the point you want with Enter key, so I think that using this technique it may be possible to build a secondary console accessible without mouse: http://www.webmultimediale.org/videoblog/2009/07/html5_nello_us_congress_video.html | ||
::: SP reply: with the javascript API to the itext elements it will be possible to build such interfaces easily using HTML5 video. | |||
* RE: I think it would be very useful a third demo with a secondary console (Play-pause) tab-navigable. It is necessary the video can start ONLY with keyboard, without even a single click. I think that this is a very simple add-on for you. The idea is like this Flash example: http://www.webmultimediale.org/guide/index.php?module=webpage&id=32&page=3 | * RE: I think it would be very useful a third demo with a secondary console (Play-pause) tab-navigable. It is necessary the video can start ONLY with keyboard, without even a single click. I think that this is a very simple add-on for you. The idea is like this Flash example: http://www.webmultimediale.org/guide/index.php?module=webpage&id=32&page=3 | ||
(see SMIL file here: http://www.webmultimediale.org/SC_1.2.5/rtmp_lis-test.smil) | (see SMIL file here: http://www.webmultimediale.org/SC_1.2.5/rtmp_lis-test.smil) | ||
::: SP reply: with the HTML5 video element and its javascript API this is already possible. | |||
* RE: For the FF bug I sent you in a previous mail (https://bugzilla.mozilla.org/show_bug.cgi?id=93149) you cannot move focus on the Object using FF, but you can move it on Play-Mute-Rewind links and start movie using Enter key. | * RE: For the FF bug I sent you in a previous mail (https://bugzilla.mozilla.org/show_bug.cgi?id=93149) you cannot move focus on the Object using FF, but you can move it on Play-Mute-Rewind links and start movie using Enter key. | ||
::: SP reply: this is a Firefox bug that I think is fixed now (Oct 09). | |||
* OG: I see a problem for embedded streams about 'readonly attribute HTMLCollection allText'. '4. Itext text extraction' says it is the entire contents of time+text, so you can do processing on the whole text, which won't be possible on streamed resources. Even if it was to preload the entire thing, it would break for 'live' sources that are realtime captioned (though that's probably very rare, but it's done on TV I think). Might want to add a boolean 'partial content' if it's acceptable to get filled as streaming goes. | * OG: I see a problem for embedded streams about 'readonly attribute HTMLCollection allText'. '4. Itext text extraction' says it is the entire contents of time+text, so you can do processing on the whole text, which won't be possible on streamed resources. Even if it was to preload the entire thing, it would break for 'live' sources that are realtime captioned (though that's probably very rare, but it's done on TV I think). Might want to add a boolean 'partial content' if it's acceptable to get filled as streaming goes. | ||
::: SP reply: It will always contain what is available - in real-time resources that would be what has been available so far. I don't think that's "partial" content either. | |||
* OG: On errors: there's an language mismatch, there probably should be a category mismatch for a category that's not in the list ? Or a warning. (or that's parse error ? Could be too). | * OG: On errors: there's an language mismatch, there probably should be a category mismatch for a category that's not in the list ? Or a warning. (or that's parse error ? Could be too). | ||
::: SP reply: yes, the error interface is still very raw. Thanks for noticing. | |||
* OG: langName: you say it's the full text, suitable for display. I was wondering where to do that conversion from language code to user visible name. Having the JS see the language code allows for doing something with it (eg, fetching a dictionary, whatever). User visible name means for en you could have English, Ingles, etc. Less useful for that. | * OG: langName: you say it's the full text, suitable for display. I was wondering where to do that conversion from language code to user visible name. Having the JS see the language code allows for doing something with it (eg, fetching a dictionary, whatever). User visible name means for en you could have English, Ingles, etc. Less useful for that. | ||
::: SP reply: no, it's not the full text, but the code, as in the spec. The browser has to map that to the visible name as it does with other interfaces. | |||
* more feedback encouraged! | * more feedback encouraged! | ||