W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2010

Re: Survey ready on Media Text Associations proposal

From: Eric Carlson <eric.carlson@apple.com>
Date: Fri, 5 Mar 2010 14:23:51 -0800
Cc: Philip Jägenstedt <philipj@opera.com>, Michael Smith <mike@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-Id: <A6D35D1E-5285-4AFA-9F60-AD8F29C2290B@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

On Mar 5, 2010, at 1:26 PM, Silvia Pfeiffer wrote:

> On Sat, Mar 6, 2010 at 5:15 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>>  I think 'media' will be extremely useful for describing the accessibility affordances in optional external tracks.
>> <trackgroup media="accessibility(audiodescription:yes)" >
>>    <track src="en.wav" lang="en" enabled >
>>    <track src="fr.wav" lang="fr" >
>>    <track src="de.wav" lang="de" >
>> </trackgroup>
> In this case, a @role attribute with the value "audiodescription"
> would achieve the same effect.
> Thus far, media queries have been used not to describe what a resource
> has to offer, but what device features the resource would be suitable
> for. I believe that is a subtle but important difference.
  Ah, but this media query doesn't necessarily describe what is *in* the resource, is simply says that a resource is *appropriate* for a user that wishes to have audio descriptions. 

  "audiodescription" may have been a poor choice to use for an example, lets use avoidance of high contrast video instead. The proposed "accessibility()" media query can be triggered based on something that a user does *not* want, so to signal that a video is appropriate for users that prefer to not see high contrast video you could use something like this:

    <video controls>
        <source src="video_low_contrast.m4v" media="accessibility(high-contrast:no)" >
        <source src="video_standard.m4v">

  In the presentation David Singer made at the media accessibility workshop before TPAC we talked about using these on <source> elements only, but I think they will be equally useful as a way to choose <track> and <trackgroup> elements.

> I believe there is a lot of work ahead of us to identify device
> features that limit the use of accessibility resources. I believe
> @media will indeed be useful, but I don't think we have discussed it
> sufficiently at this stage to necessitate it's inclusion.
>>> Incidentally - have any browser vendors implemented support for the
>>> @media attribute on the video and audio elements? I'd be curious about
>>> test cases there and whether they apply to external text associations.
>>  WebKit supports media queries on the <source> element.
> Out of curiosity: Do you have public test cases?
  Yes. Most of our media tests are here: http://trac.webkit.org/browser/trunk/LayoutTests/media. It looks like we only have one that only looks at "media", video-source-media.html, but video-source-error-no-candidate.html and video-source-error.html both use media queries to test somethings else.

Received on Friday, 5 March 2010 22:30:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC