I've read through the discussion and have these comments and questions:
What is the use case to justify an API (and associated synchronization
complexity) for access to cues that is not solved by captions for those
who can't hear the audio and audio descriptions of visual media for
those who can't see the video?
Since it's early in the discussion of this issue I think this topic
needs to be separated from the rest of the discussion. Alex can you
move that to a separate section like you did for the Registry API?
At least at this point I'm not in favor of the media control methods.
Developers should provide accessible GUI controls. The developer would
have to implement the access in any case and having access through the
GUI would eliminate adding the code for these new methods on both sides
of the interface. If the app developer does a correct implementation of
the GUI there would be no extra coding required in ATs.
There are other things I could comment on but would like to first focus
on whether or not we actually need to continue the discussion.
Pete
--
*Pete Brunet*
a11ysoft - Accessibility Architecture and Development
(512) 238-6967 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
