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

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sun, 01 Jul 2007 20:40:55 +1000
Message-ID: <468784B7.8070001@lachy.id.au>
To: aurélien levy <aurelien.levy@free.fr>
CC: public-html@w3.org

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.

-- 
Lachlan Hunt
http://lachy.id.au/
Received on Sunday, 1 July 2007 10:41:08 GMT

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