On Fri, Jun 17, 2011 at 8:34 AM, James Teh <[email protected]> wrote: > On 9/06/2011 9:50 PM, Alexander Surkov wrote: >> However specialized interfaces allows to provide a common >> way to deal with different objects and can be used to fix web page >> accessibility errors. In the case of media interface screen reader can >> provide unified way to play or pause the media for example. This can >> be really be a good idea when web page authors didn't provided UI to >> control the playback but added keyboard shortcuts and mouse gestures. > This is a very slippery slope. By that logic, we should provide > interfaces to fix all sorts of accessibility defects due to bad > authoring; e.g. inaccessible drop down menus, inaccessible Flash, etc. > Admittedly, these are poor examples, but the point stands. In any case, > you could achieve the same result by exposing fake, off-screen UI > controls for the video. > >> I considered the idea of live regions usage, it's really good until >> the media shouldn't be stopped until screen reader finishes the >> reading. To handle this we should introduce new approach that's isn't >> connected with aria live regions. > Why? It can be generalised to a live region which requires client > notification when read. For example, we could use @aria-live="polite" > @aria-liveNotifyWhenDone="true", the latter meaning that the AT must > notify the browser via some call that it has finished handling the > region. This would still require one method, but it's better than > implementing a whole new concept. (Note that I'm still not convinced > this is ideal for an a11y API, but I think if we're going to do it, it > should be as general as possible.) > >> On the another hand since extended text is supposed to be >> visible by screen readers only > Maybe there are sighted users who might want to see it as well? Making > this screen reader specific defeats inclusive design. I agree that most > sighted users won't want it, but that doesn't mean that none will. I > guess it could be off-screen or similar when not visually available.
To clarify how this currently works in HTML5: The way in which it is specified, text descriptions are not exposed visually by browsers, but only exposed to Web developers through a JavaScript API. The text is not available on the page's DOM. If a Web developer decides to also expose text descriptions visually, they have to create a visual display themselves. I've seen developers do this, but it's a custom solution and not something that Web browsers are expected to implement, since text descriptions are particularly targeted at being read out by a screen reader type application. BTW, it is explicitly mentioned that eyes-off applications (something like watching a video while cooking) could make use of text descriptions, too. In this case, the user would require some voicing application installed - something that is similar to a screen reader. In the future we may see such functionality being natively integrated into browsers. But I guess we have to deal with this situation now. Cheers, Silvia. _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
