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

On Jul 1, 2007, at 5:40 AM, Lachlan Hunt wrote:

>
> aurélien levy wrote:
>> Just a reel example:
>> yes i can improve Flash content accessibility but for a perfect  
>> experience user need to have have Jaws >= 7, the right plugin  
>> version, IE and windows, so there is still a lot of case where the  
>> user have the plugin and still can't have access to it even if the  
>> content is itself accessible. I don't even mention the fact that  
>> actually a keyboard user in firfox can't have access to any plugin  
>> content since i need the mouse to focus the object or the fact  
>> that an accessible flash is still a lot more difficult to use and  
>> understand than his accessible html fallback (flash accessibility  
>> is just a focus order and linear list of textual alternative).
>
> That's a good example of how technical limitations can have an  
> impact on accessibility, but it's really does just boil down to  
> technical limitations.  The question is, is HTML the right place to  
> solve such limitations?  I believe that any HTML solution should be  
> considered short term, where the longer term solution is to resolve  
> the technical issues with the Flash plugin, Firefox and screen  
> readers  If that's the case, should we really be spending our time  
> developing short term solutions?

We're not spending out time developing short term solutions, we're  
spending undue time discussing whether the solutions we already have  
should be developed and promoted. In other words, we have faciliaties  
in HTML4.01 that constitute best practice for accessibility and  
fallback (<object>, <table>@summary, etc.). Clearly these address a  
particular use-case and do so in a best practice manner. There are  
issues in communicating to author s how best to use these. There are  
issues with non-conforming UA implementations. Yet neither of those  
problem areas could possibly justify dropping those best practice  
approaches. Quite to the contrary, I believe we should extend those  
best practices to <video>,  <audio>, and <picture>. Now, if the WG  
can come up with other better practices that could be a rationale for  
deprecating the past best practices. Likewise if the WG comes up with  
a brilliant strategy to deal with UA or author conformity that  
requires changing these practices, I'm all ears. Without that, I  
can't think of any reason not to continue accommodating the use-cases  
accommodated by HTML4

> For it to be worth the effort, any short term solution we develop  
> really has to work in existing UAs, because if it doesn't, then  
> vendors are better off working on fixing the long term solutions  
> now, instead of delaying while they implement the short term solution.
>
> There are various possible solutions that could be considered:

One other I would prefer to see.

* 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)

> * <noembed>
>   - pro: I think it works in some UAs already (need to test it).
>   - con: no direct association with the specific embed element.
>
> * <embed>fallback</embed>
>   - pro: consistent with <object> fallback.
>   - con: not backwards compatible at all, embed is an empty element.
>
> * Providing alternative content in the same page or linking to it.
>   - pro: already works in every UA.
>   - con: ?
>
> * <embed alt="">
>   - pro: works in Opera already
>   - con: doesn't seem to work in other UAs (need to test).
>
> * Use <object>fallback</object> instead.
>   - pro: Already exists
>   - con: IE limitations, though there may be workarounds (need to  
> test).

Take care,
Rob

Received on Sunday, 1 July 2007 20:05:20 UTC