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

The answer of course is: Yes! We do need to spend the time to develop a 
good fallback solution for HTML, but its not just for the short term, 
its also for the long term, it can then be a fallback mechanism for 
future plugins and embedded content, etc...

The possible solutions you present are a good start, I personally feel 
that <object>fallback content</object> may be the best solution, as 
although there are issues for IE6, the technique is backwards compatible 
with the HTML 4 specification.


Cheers,
Andrew Ramsden



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?
> 
> 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:
> 
> * <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).
> 
> As well as investigating how well each of these works and how they solve 
> the problem, we should also look at how sites already address this 
> issue.  For example, I believe it is fairly common for flash sites to 
> provide an HTML only alternative, and allow the user to decide which 
> version they want.
>

Received on Sunday, 1 July 2007 17:06:51 UTC