- From: David Singer <singer@apple.com>
- Date: Mon, 31 Jan 2011 09:43:52 -0800
- To: Eric Carlson <eric.carlson@apple.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Jim Allan <jimallan@tsbvi.edu>, david.bolter@gmail.com, Charles McCathieNevile <chaals@opera.com>, Sean Hayes <Sean.Hayes@microsoft.com>, WAI-UA list <w3c-wai-ua@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Philip Jägenstedt <philipj@opera.com>
You are right. This strawman (which is quite aggressive) should force *en*able the built-in controller. So, this is a setting "source-directed play is disabled" (meaning auto-play, scripts, and so on). Only the user gets to choose what to play and when. Maybe there is some indication (like what?) of what the page would have played if it had been allowed (the page is 'trying' to play this element but you've told it not to)? On Jan 28, 2011, at 8:30 , Eric Carlson wrote: > >> This is not ideal, especially for audio-only elements, where it's not obvious what affordance would work, and it is probably not obvious to the user that something *might* have played (and hence they should look for the affordance). >> > I don't think this works at all for a page with lots elements, or with <audio> and <video> elements are are not in the DOM. For example, what sort of UI would you expect for a page with 50 hidden audio elements? Or how is a user that can't see the page supposed to quickly find the noisy element in a page one <audio> element but lots of other elements? > > eric > > David Singer Multimedia and Software Standards, Apple Inc.
Received on Monday, 31 January 2011 17:44:29 UTC