My accessibility work for Mozilla is showing first results.
I have now implemented a demo for the previously proposed <itext> element. During the development process, the specification became more concrete.
I’m sure you’re keen to check out the demo.
Please note the following features of the demo:
- It experiments with four different types of time-aligned text: subtitles, captions, chapters, and textual audio annotations.
- It extends the video controls by a menu button for the time-aligned text tracks. This enables the user to switch between different languages for the different tracks.
- The textual audio annotations are mapped into an aria-live activated div element, such that they are indeed read out by screen-readers; this div sits behind the video, invisible to everyone else.
- The chapters are displayed as text on top of the video.
- The subtitles and captions are displayed as overlays at the bottom of the video.
- The display styles and positions are supposed to be default display mechanisms for these kinds of tracks, that could be overwritten by the stylesheet of a Web developer, who intends to place the text elsewhere on screen.
In order to “hear” the textual audio annotations work, you will need to install a screen reader such as JAWS, NVDA, or the firevox plugin on the Mac.
As far as I am aware, this is the first demo of HTML5 video accessibility that includes support for the vision-impaired, hearing-impaired, and also for foreign language speakers.
There have been initial discussions about this proposal, the results of which are captured in the wiki page. I expect a lot more heated discussion will happen on the WHATWG mailing list when I post it soon. I am well aware that probably most of the javascript API will need to be changed, and also some of the HTML.
Also please note that there are some bugs still left on the software, which should not inhibit the discussion at this stage. We will definitely develop a newer and better version.
I am particularly proud that I was able to make this work in the experimental builds of Opera and Chrome, as well as in Safari with XiphQT installed, and of course in Firefox 3.5.
Hi! I made known in Italy your useful work in my videoblog
http://www.webmultimediale.org/videoblog/2009/07/video_con_sottotitoli_e_senza.html
It is really very interesting to have an accessible video without using a player plugin.
Hi Roberto
I saw it and Google translate also allowed me to read it. 🙂
Thanks for spreading the news!
It looks interesting to me, but from a quick read I’d say that in the current proposal (at least in the demo) there’s too much boilerplate code. At least one of the arguments pro HTML5 is that it doesn’t require more typing than necessary (see the doctype, meta charset, etc.).
So, personally, I’d drop @type and shorten @category. I’d also put @charset in the SRT file itself, or at least in the HTTP headers, where it is less likely to be out of sync with the content. (I guess that’s not possible with the format as it stands today, but it needs a better spec anyway. I guess a charset declaration could be added at the same time.) Finally, I’d make @display default to “auto”, and make the behavior dependent on the language and the category. (E.g. always display the cue points.)
I.e., instead of I’d prefer something closer to .
(Also, shouldn’t that use “ISO-8859-1” rather than “ISO-8859”?)
Ms2ger,
Thanks for your feedback! Would you mind re-posting those examples that seem to have been munged. Please escape < with < .
SRT as it is currently defined does not contain the charset, which is why it is an attribute in itext. This why the proposal allows for different file types.
The next file types I am going to experiment with are LRC and DFXP. It may well not be necessary to have a type attribute for these, but it makes it more explicit.
As for @category and @display – I have indeed a new suggestion for how to specify these with less “text” – it includes the creation of a hierarchical element on top of the itext element, see https://wiki.mozilla.org/Accessibility/Experiment1_feedback#Thoughts_.2F_Feedback and itextlist.
As for ISO-8859-1 – it is indeed different to ISO-8859, since some characters were displayed wrongly if I used the other one. I am not a charset expert, so cannot explain why, but I know when choosing the wrong one I got the wrong characters.
That should’ve been <itext lang=”es” type=”text/srt” charset=”ISO-8859″ display=”auto” src=”subtitles/elephant.spanish.srt” category=”CC”></itext> and <itext lang=”es” src=”subtitles/elephant.spanish.srt” cat=”CC”> respectively. (I seem to have forgotten to mention that I’d drop the end-tag too.)
Thanks, Ms2ger, for re-typing the code. I know what a pain it is. 🙂
I don’t think we can do without the @charset attribute, but I do agree that @display may not be necessary. Or rather, it could be associated with a superior tag like the itextlist that I am currently considering. That would also remove the @category attribute.
It would be something like:
<itextlist category=”CC” @activelang=”es”>
<itext lang=”es” src=”elephant.spanish.srt” charset=”ISO-8859″/>
<itext lang=”en” src=”elephant.english.srt”/>
</itextlist>
Hello,
This is perfect. I am testing the demo with NVDA. It picks up audio text fine. However I am perhaps doing something wrong I seem to be unable to change the itext language and also I am unable to locate the list of cue points. I am testing with latest nightly of Seamonkey 2.0 and Firefox 3.5.
I can recognize the video element which has control buttons disabled by default, then I can see a few hiperlinks saying play, stop, loudness and text. Is the text link supposed to trigger an action allowing to do something?
I know comments like this may not be appropriate in such an early stage of development but Iam so excited about it so I’m trying to work out what I am doing wrong.
Thanks.
@pvagner : these comments are exactly what I would like to get!
To change the itext language, you have to go through the menu that is created through the “text” button (which I have now alt annotated after some other feedback to “Access Subtitles, Captions and Audio Descriptions – press space bar”). This opens a menu with the different time-aligned text types, each with a submenu of the different languages. I have been made aware that this is not accessible but have not found out yet how to fix that. I have a hunch that it may need to be a treewidget according to http://www.w3.org/TR/wai-aria/ , but haven’t tried that yet.
Thanks a lot for your help!
No problem. Itextlist does indeed look promising (apart from the name, but I don’t have a counter-proposal).
@Ms2ger any proposals for new names and generally better naming welcome!