W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: html 5 and accessibility issue - need of fallback content

From: Robert Burns <rob@robburns.com>
Date: Sun, 1 Jul 2007 16:01:13 -0500
Message-Id: <BEEB75DF-1F03-40D9-BAF0-CB3527ED4A2B@robburns.com>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, aurélien levy <aurelien.levy@free.fr>, public-html@w3.org
To: Henri Sivonen <hsivonen@iki.fi>


On Jul 1, 2007, at 3:37 PM, Henri Sivonen wrote:

>
> On Jul 1, 2007, at 23:05, Robert Burns wrote:
>
>> * Not adding <embed> as an author conforming element (rather just  
>> specify UA conforming algorithms for <embed> including adding @alt  
>> and @longdesc support). Recommend the use of <object><param/ 
>> >ffallback content</object> in the short-term with some other  
>> simpler solution in the long-term if we think that's necessary.
>> 	-  pro: already supported
>> 	- pro: provides a mechanism for fallback content that should be  
>> provided and encouraged by the WG (a fallback mechanism that's  
>> much simpler than <noembed>)
>> 	- con: may be more complicated to author than <embed> for IE (I'm  
>> not sure if it is, but I could use some help in thinking of a con)
>
> con:
> According to http://weblogs.macromedia.com/accessibility/archives/ 
> 2005/08/in_search_of_a.cfm Flash embedding methods that don't use  
> <embed> have worse real-world behavior with AT than the Flish  
> default embedding markup that uses <embed>.

I'm not seeing how you're reading the document that way. The results  
table shows no problem any of the AT solutions tested. The author  
doesn't mention in the  prose any problem with AT. Could you provide  
some more details on your reading of that article?

There is only one implementation that exhibited an issue with the  
simplest <object> approach: Firefox 1.0.4 The other <object>  
solutions worked across UAs (except Flash Satay had problems with  
JAWS; this was not the approach I was advocating).

Obviously there will always be practical issues that authors have to  
deal with (e.g., bugs in a particular implementation/version). If we  
start adding those cons to these list the reports will become  
unmanageable. I think it goes without saying that:

pro simplifies the language (for facilities removed)
con: complicaates the language (for facilities added)
con: countless bugs exist in deployed versions of UAs and may be  
introduced in future deployed versions of UAs

I don't think its all that useful except in very noteworthy cases.

Take care,
Rob
Received on Sunday, 1 July 2007 21:01:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT