RE: Firing media events early for throttled downloads

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