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

I totally agree with that but actually, it an accessibility issue too.

This is an open issue of wcag 2.0 because lot of people disagree the 
fact that a plugin manufacturer can claim that is technology is 
accessible if it's just working for one AT and one UA (see wcag 2.0 
accessibility supported concept)

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

So, there is technical need for fallback content (absence of plugin for 
example), but there is a need to access it even if the plugin is there 
for accessibility reason (and a need of UA access to them with keyboard)

Aurélien
>
> There are a couple of levels of accessibility at play here.
>
> 1. embedded content should be accessible itself. If you embedding
> flash, you should be producing accessible flash. If you are embedding
> video, it should contain captions and audio description, etc. This is
> all fine, it's accessibility related, it's quite challenging to do,
> and it's largely irrelevant to the HTML WG as it must be managed
> entirely outside of HTML anyway.
>
> 2. providing a fallback for when a plugin cannot be used. For example,
> I run 64bit firefox at home here. There is no 64bit plugin for flash.
> How can authors of HTML pages provide a fallback for me (something
> better than the browser "missing plugin" message?) This is where it
> would be useful to be able to use <embed> ... fallback ... </embed>.
> This is highly relevant to the HTML WG as it is directly related to
> fallback mechanisms within HTML itself.
>
> Just want to highlight the difference between (1) making plugin
> content accessible and (2) providing fallbacks for plugin content.
> Both are important, but only the latter can be addressed through HTML.
>
> Note that this latter is usually not about "disabilities" but about
> technical constraints. Some of these are temporary (64bit flash
> doesn't exist), there are often workarounds (I could install a 32bit
> browser in my 64bit OS), but sometimes it is entirely out of the users
> hands (the prime example is the locked down corporate browser you are
> allowed - subject to strict usage policies - to use at your workplace
> which you cannot, and absolutely must not, and had better not speak
> of, customising).
>
> As authors caring about accessibility, we need HTML to provide the
> mechanisms to support users as best we can in all these situations.
>
> Places emphasising these requirements are:
>
> http://www.w3.org/TR/WCAG10-TECHS/#tech-scripts
> http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html#degrade-gracefully 
>
> http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html#universal-access 
>
>
> I also just read this gem :)
> http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html#priority-of-constituencies 
>
>
> We are very much talking about the needs of users and authors here,
> and in all threads relating to metadata/fallback mechanisms around
> embedded content (and tables).
>
> cheers
> Ben
>
>
>

Received on Sunday, 1 July 2007 09:36:26 UTC