W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: Acessibility of <audio> and <video>

From: Leif Halvard Silli <lhs@malform.no>
Date: Sat, 06 Sep 2008 02:48:05 +0200
Message-ID: <48C1D345.5020904@malform.no>
To: James Craig <jcraig@apple.com>
CC: public-html@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>

James Craig 2008-09-06 01.41:

> Leif Halvard Silli wrote:
> 
>> VoiceOver is based on WebKit - aka Safari.
> 
> VoiceOver works with Safari/WebKit, but it is not based on Safari/WebKit.


Based on working w/Safari. (Next para mentions VoiceOver + Opera.)

 
>> This leads to this strange contradiction: While Apple's Safari 
>> supports @longdesc, their Safari based screen reader doesn’t. (The 
>> same contradiction applies for the screenreading support in Opera on 
>> Mac OS X - which also uses VoiceOver.)
> 
> Even if VoiceOver was based on Safari, this is a flawed argument. Just 
> because a property is in the DOM doesn't mean that the browser knows how 
> to map it to an external API. By the logic of your statement, I could 
> also add a custom "myAttribute" attribute to the DOM and then state that 
> the value of "myAttribute" wasn't accessible.

But then @longdesc isn't a privat attribute, but an old 
accessibility attribute which perhaps should have been on the 
boilerplate for making VoiceOver work with Safari just as it was 
on the boilerplate for impelementing DOM 1.0 in WebKit?

>> Anyway, my point was to say that the support for @longdesc is much 
>> better than Lachlan claims simply because all the mayor browsers, on 
>> which the screen readers usually are based, they support it.
> 
> The DOM is pretty freeform, so all browsers also support @myAttribute, too.


All browsers supporting DOM 1.0 know that @cite and @longdesc 
contain URI-s. They at least needs to be told, each and every one, 
what @myAttribute contains.
-- 
leif halvard silli
Received on Saturday, 6 September 2008 00:48:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:58 UTC