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

Re: Survey ready on Media Text Associations proposal

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 6 Mar 2010 08:26:05 +1100
Message-ID: <2c0e02831003051326n46800047tad6c4a7d93786212@mail.gmail.com>
To: Eric Carlson <eric.carlson@apple.com>
Cc: Philip Jägenstedt <philipj@opera.com>, Michael Smith <mike@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Sat, Mar 6, 2010 at 5:15 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>
> On Mar 4, 2010, at 9:21 PM, Silvia Pfeiffer wrote:
>
>>
>>
>>> Do you still want to keep the
>>> enabled *property* so that scripts can switch between different tracks of a
>>> group, just like the browser context menu?
>>
>> I assume you are referring to the JavaScript API with *property*? If
>> so, yes, I think a Web Developer should be able to set a default
>> through the @enable attribute, and ask the track about its state
>> through the enabled property, then be allowed to react accordingly.
>>
>  I agree.
>
>>> I am not very optimistic about UA
>>> track selection being very useful being applying the 'media' attribute.
>>
>> Those media queries that apply to this (as well as the video element)
>> actually still need to be defined. As with the JavaScript API, we
>> could decide to leave the media attribute out for the moment and add
>> it at a later state when we are sure that we actually have media
>> queries that help in the resource selection process.
>>
>  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.

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?


Thanks,
Silvia.
Received on Friday, 5 March 2010 21:26:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:03 GMT