- From: John Foliot <jfoliot@stanford.edu>
- Date: Fri, 5 Jun 2009 16:08:18 -0700 (PDT)
- To: "'Ian Hickson'" <ian@hixie.ch>, "'Robert O'Callahan'" <robert@ocallahan.org>
- Cc: "'public-html'" <public-html@w3.org>
Ian Hickson wrote: > we have an explicit "autoplay" attribute which we should > be encouraging authors to use instead. Whilst this may be a better programmatic way of firing a media stream, I would suggest that "autoplay" be specifically *discouraged* in all documentation, as it conflicts with AT that requires audio output (screen readers). The launch of linked or embedded multi-media content should be a user-choice decision, and not an author-choice one: User-agents (who seem to be driving this whole thing) should also have specific over-ride controls built into their system, so that end-users can 'refuse' author directives to auto-start, in keeping with the axiom 'author proposes, user disposes'. "I believe that if we ensure that we have good tutorials for this <del>API</del><ins>feature</ins>, we can sidestep this <del>issue</del><ins>problem</ins>." Examples in the wild: BAD - Using your favorite screen reader, visit: http://cnettv.cnet.com/obama-message-israel/9742-1_53-50072715.html GOOD - http://w20.wvfm.fm/movies/ (the "celebration cinema" ad) ...Note that this example also involves/involved author awareness (as the audio off setting is set by the developer), but this is the type of functionality that we need to give to the end user - so that by default, if they *need* to not have audio auto-fire (and it could also be argued motion as well, although likely less severe), they could set that as a global setting for their user-agent. (As an observation - if you have ever worked in a cube farm, you might also appreciate not having audio auto-fire from your cube while you are hard at work doing 'research'<wink> on the web...) JF
Received on Friday, 5 June 2009 23:09:00 UTC