Hi, Jamie. I can see your point but I'm not sure I share it entirely. In general I agree that screen reader should expose that what's visible and operable for sighted users. This idea makes all specialized interfaces unneeded. 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. While this is operable by screen reader users still but this is a discoverability problem.
The proposed approach of cues handling missed the support of multiple ATs. It's a huge gap from the point of API correctness (Firefox doesn't work properly with multiple ATs running the same time but this doens't excuse). I think it can be fixed by this or that way making it more complicated but I think we should figure out if we need special interface for media controls at all. 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. And this makes me feel this is very hacky way. On the another hand since extended text is supposed to be visible by screen readers only then it implies that aria live regions shouldn't be visible what might be a problem to process them correctly on browser and AT levels. Thank you. Alex. On Thu, Jun 9, 2011 at 8:08 PM, James Teh <[email protected]> wrote: > Hi. > > While I recognise the importance of media accessibility, I think special > purpose interfaces are generally best avoided and so extreme caution > needs to be exercised when considering them. I think we need to clearly > determine the use cases for each interface and part thereof. My initial > feeling is that most of this either does not belong in an accessibility > API or can be done in a far more general way. > > I don't see the need for a special interface to control media. The media > playback controls can already be exposed as normal controls to ATs (e.g. > buttons, sliders, etc.), just as they are now, with the application > providing keyboard shortcuts as appropriate. Selection and toggling of > media tracks can (and should) similarly be handled by the application > using a standard UI. > > Output of text cues can be generalised and handled using live regions. > > The only piece remaining is pausing of audio while the AT reports the > cue to the user if that reporting would overlap with another cue. This > really does venture outside the scope of current accessibility APIs, as > ATs don't generally change application behaviour, but rather allow > exposure and interaction with UI. I don't really have a good solution > for this yet. However, the proposed solution has several problems: > 1. The event could be picked up by multiple ATs, but not all of them may > want the pause on exit behaviour. An event shouldn't generally change > application behaviour just because an app picked it up; it should be > passive. Also, keep in mind that many a11y clients register for all > events, even if they don't use them all. > 2. What if a user is using multiple ATs; e.g. screen reader and > magnifier? One might issue a request to fetch the next cue, but another > might not be finished outputting it yet. > > Jamie > > On 8/06/2011 7:46 PM, Alexander Surkov wrote: >> Hi. >> >> Based on my talk with Silvia couple days ago I think I can suggest API >> for your consideration - >> https://wiki.mozilla.org/Accessibility/IA2_1.3#IAccessibleMedia_interface. >> >> Thank you. >> Alex. > > -- > James Teh > Vice President, Developer > NV Access Inc, ABN 61773362390 > Email: [email protected] > Web site: http://www.nvaccess.org/ > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
