- From: Philip Jägenstedt <philipj@opera.com>
- Date: Sun, 30 May 2010 14:05:59 +0800
- To: "Eric Carlson" <eric.carlson@apple.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "John Foliot" <jfoliot@stanford.edu>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
While a wishlist is useful on the long-term and as a primer for people like me on what accessibility folks think is important, I get the feeling that some of the requirements are more important than others. For example, I would imagine it is absolutely critical that captions be delivered in a text format as opposed to bitmaps, while it is not nearly as important that one can direct a particular soundtrack to headphones only. I would like to see a list of requirements which are truly critical for accessibility, avoids trivial requirements which are going to be fulfilled regardless (e.g. that a text format be used) and avoids things which are already required by the spec. I would also really like to see more direct feedback on the actual direction the spec is going with <track>, WebSRT, etc. After browsers start implementing and shipping, it may already be too late. Philip On Sun, 30 May 2010 09:03:04 +0800, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Hi Eric, and also Philip, > > I agree that there are many details that we need to address in the > requirements document and it will be great to start a detailed > discussion about every single topic brought up in the requirements > document. I also think that some of the requirements may well go > beyond what is technically possible now. However, I do not think that > it is the aim of the document to only specify what should actually go > into HTML5 now. Instead, I look at the requirements document simply as > a wishlist created by folks with an accessibility background of things > that would be awesome to have around audio and video on the Web. And I > think it is good to capture this, even if some of it can not (yet) > technically be realised. > > It is also important, though, for accessibility folks to understand > that this is a wishlist and may not result in all of this technology > actually being available in HTML5 in the near future. Thus, it is good > to flag this early. > > Maybe we need to make a general addition to the document stating this > clearly? John, Janina, what do you think? > > Also, we need to take on board the points where Eric and Philip have > directly pointed out that sentences/requirements are not > comprehensible and explain these better. > > I suggest what we do with your inputs is the following: > 1/ add an explanation at the top that this is a list for what should > be made available in a perfect world and that this may result in a > long-term work-plan with some more important dimensions solved earlier > than others. Maybe we can even come to an agreement on what is of > higher priority? > 2/ go through and fix up the requirements that are not understood. > 3/ start discussions on the mailing list for every single section to > get closer towards technical recommendations on how it could be done > in HTML5. > > Cheers, > Silvia. > > > On Sat, May 29, 2010 at 9:38 AM, Eric Carlson <eric.carlson@apple.com> > wrote: >> All - >> I haven't responded to the WBS survey yet, but here is my feedback. >> I think there are enough issues with the document that it would be >> helpful >> for the task force to have a discussion via email to sort it all out. >> eric >> >> Audio Description >> This content type will be very difficult or impossible to support on >> some >> resource constrained devices because it requires the media engine to >> decode >> and play more than one audio stream simultaneously. For example, with >> the >> audio chips used in many modern cell phones it is impossible to decode >> and >> play more than one stream of digital audio data at a time. >> • (AD-4) Any digital audio format should be able to handle "real human >> speech", it doesn't need to be called out. Synchronizing audio >> and video loaded from different files can be very difficult to do well. >> • (AD-5) and (AD-6) These require multiple audio streams to play >> simultaneously. This is not possible on all devices. >> • (AD-7) What does "The degree and speed of volume change should be >> under >> provider control" mean? Is it really crucial for this feature? >> • (AD-9) We have not been able agree on required audio and video codecs, >> what makes you think we will be able to agree on a code specialized for >> speech? Is it really required? >> • (AD-11) This requires multiple audio streams to play simultaneously. >> See >> above. >> • (AD-12) What does this mean? What are programs and channels? >> >> • (AD-13) I have no idea what this means. >> >> • (AD-14) What does "support metadata" mean? Digital media files can >> already >> carry metadata, is the requirement to expose it to the DOM? >> >> Texted Audio Description >> If we want people to be able to create interoperable pages, this >> requirement >> must specify a TAD file format. >> (TAD-1), (TAD-2), (TAD-4), and (TAD-5) Aren't these all requirements >> for >> the TAD file format? >> (TAD-3) This won't be possible on all platforms, for example devices >> that >> only allow one mode of audio output. >> >> Extended audio description >> This is impossible to evaluate without a specification for an EAD file >> format. WCAG2 recommends using SMIL 1 or 2, which would be an *enormous* >> implementation burden an a UA. >> >> Clear audio >> (CA-1) - (CA-3) These require a UA to play multiple tracks of audio >> simultaneously. As previously noted, this is not possible on all >> devices. >> >> Content Navigation by Content Structure >> This will require a mandated CN file format if we want interoperable >> content. The two formats mentioned are quite complex and will require >> enormous implementation effort. Do we actually *require* that level of >> sophistication? >> (CN-2) - This may not be possible with all CN formats as not all are >> self-contained. >> (CN-3) - (CN-5) These are functions of a CN file format. >> (CB-8) - (CN-10) I don't know what these mean. >> >> Captioning >> (CC-1) Not all media files have audio. >> (CC-17) Does this mean that captions are rendered from more than one >> external caption file simultaneously? >> (CC-25) What must a UA do differently for edited vs full verbatim >> captions? >> >> Extended Captioning >> (ECC-1) What does this mean? What is the format of "metadata markup"? >> (ECC-2) What are "other activation mechanisms"? >> (ECC-4) How does this work? Who decides if "overlap is OK ..."? >> >> Sign Translation >> Decoding and rendering multiple streams is even more difficult with >> video >> than with audio. Video decoding hardware used in many mobile devices is >> not >> able to decode more than one video stream simultaneously. >> (SL-1) and (SL-3) Playing multiple media files in sync is not currently >> supported by HTML5, and will be a significant amount of work for some >> UAs. >> >> Transcripts >> (T-2) Does this affect page layout, eg. does change the size of the >> <video> >> element or appear above other page content? >> How will this work on a device with a small screen or a device that only >> allows fullscreen playback,? >> I don't understand "If the author chose to create a new interface using >> scripting, that interface MUST map to the native controls in the user >> agent". Controls implemented with scripting should *use* the same >> interface >> to control a media file, but they do not use the native controls. Like >> Philip, I suggest we add a requirement that it must be possible to >> enable >> native controls even if a page has custom controls. >> >> Granularity Level Control for Structural Navigation >> I don't understand this requirement at all. >> >> Time Scale Modification >> (TSM-2) As I have noted before, it is not possible to change speed >> without >> changing pitch on all devices that are capable of playing digital audio. >> (TSM-3) - (TSM-5) These are already required by the HTML5 spec. >> >> Production practice and resulting requirements >> This is advice for people authoring media, not HTML. It isn't something >> the >> HTML WG needs to consider. >> >> Discovery and activation/deactivation of available alternative content >> by >> the user >> (DAC-1) - (DAC-1) How will the user control reflow and layout? >> (DAC-4) Isn't this fundamental to the concept of an alternative? If it >> needs >> to be mentioned at all, it should be in the section(s) about specific >> alternatives. >> (DAC-5) This needs to be fully specified, eg. what happens when >> alternative >> content doesn't fit into the <video> region, etc. >> (DAC-7) This should be mentioned in the section(s) about alternative >> content. >> (DAC-8) This changes behavior of 'autoplay' and 'preload', say so. >> >> Requirements on making properties available to the accessibility >> interface >> (API-4) Why is this an issue for the HTML WG? >> >> Requirements on the use of the viewport >> (VP-3) Need details about how this is supposed to work, eg. does the >> video >> pop up over the page content or does the rest of the page reflow? Is >> page >> zoom enough? "with the ability to preserve aspect ratio" - when would >> the >> user ever not want to preserve aspect ratio? >> (VP-5) All existing browser, and many stand-alone media player >> applications, >> place controls along the bottom edge of the movie. Where should they go >> instead? >> >> Requirements on the parallel use of alternate content on potentially >> multiple devices in parallel >> (MD-3) I don't understand this, an example would be helpful. >> (MD-4) "This assumes the video element will write to the DOM" - does >> this >> mean the media element's properties are accessible via the DOM? >> (MD-5) "e.g., by checking a box ..." because this document is about >> *media* >> accessibility, the example should be about a media element >> (MD-7) I don't understand this. >> >> On May 27, 2010, at 9:58 PM, John Foliot wrote: >> >> Hello All, >> >> I just wanted to send out a quick note about this very important survey >> (scheduled to close Wednesday, 2 June 2010), which is envisioned as >> much as >> a straw poll as anything else. >> >> It is important that this document be *very* right, as it will become >> the >> basis for a number of critical decisions moving forward, and having a >> complete Requirements Document will be hugely beneficial when it comes >> to >> some differing views down the road, as it will contribute significantly >> in >> removing 'emotion' from the discussion (and having broad consensus >> within >> the Task Force will be important). >> >> Even if you really don't think you have much to contribute here, please >> take >> a few minutes to review what we have... maybe we *do* have it right, but >> this really is a "many eyes" work effort at this time, and if one extra >> requirement or equivalent feedback comes back that improves what we have >> then it has been a worthwhile exercise. As well, if you know >> individuals or >> organizations in your locality that might have something to contribute, >> feel >> free to solicit their feedback as well. >> >> Survey: >> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/ >> (Note the Draft Requirements are listed in the survey) >> >> Requirements: >> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements >> (for those not part of the TF, but may have feedback) >> >> (If you know of any such individual or group, but require more time for >> their feedback, please ping me.) >> >> Thanks in advance for your participation! >> >> JF >> >> ************** >> >> >> A survey on media accessibility requirements is available: >> >> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/ >> >> The media sub-group discussed this survey 26 May 2010 and it was >> announced >> to the general task force 27 May 2010. This survey is to gather opinions >> on Media Accessibility Requirements. Each of the Alternative Content >> Technologies and System Requirements are separately presented for >> feedback. >> >> As a point of interest, there are 110 numbered requirements, with a lot >> of >> related explanatory material. In the survey this is presented as 17 >> separate >> questions for input. Please allocate enough time to complete this >> survey. ;) >> The survey is currently scheduled to close Wednesday, 2 June 2010, at >> the >> end of the day Boston time. >> >> If you need to work on this in multiple sessions, you can always enter >> as >> many answers as you can, submit them, and return to the survey later. It >> will still have your original answers and will allow you to modify them >> and >> enter new answers. Just remember to submit your work at the end of each >> session. >> >> Michael >> >> >> > -- Philip Jägenstedt Core Developer Opera Software
Received on Sunday, 30 May 2010 06:06:57 UTC