Re: Please vote on the canvas accessibility proposal

Hi Sylvia,

>Sorry I have to
>keep asking since it seems to me that if there is an issue with
>canvas, the same issues apply to fallback in the video element, right?

I am not sure if they do as i have not looked at the video situation in
detail.

>Is this because the AT doesn't support the canvas element yet? I would
>think that it is expected of AT that supports HTML5 markup to ignore
>"fallback" on an element that only applies to legacy browsers.

canvas is a visual element, like <img> AT such as screen readers cannot
support it as such, but they can access alternatives if the browser that a
person is using with their AT exposes the alternative.  Another example
would be that the viusal aspects of a video are not accessible to a blind
user, so she needs audio description provided as an alternative, even though
the browser she is using supports the video element.

>This is what I don't understand. If it is a modern Firefox, then this
>message should not ever be displayed, not on screen and not to AT. Can
>you explain?


the spec [1] describe how the "fallback" should be exposed and how the
elemnts in the subtree should be in the tab order, regardless of whether the
browser supports canvas or not. The canvas is nothing more than an animated
image, it contains no useful non visual information that is exposed via the
canvas API.

[1]
http://dev.w3.org/html5/2dcontext/#focus-management

regards
steve

On 23 February 2010 22:17, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote:

> Hi Steven,
>
> Thanks for your continuing patience in explaining. Sorry I have to
> keep asking since it seems to me that if there is an issue with
> canvas, the same issues apply to fallback in the video element, right?
>
>
> On Wed, Feb 24, 2010 at 2:13 AM, Steven Faulkner
> <faulkner.steve@gmail.com> wrote:
> > if the content of the canvas sub tree is exposed to AT and focusable
> > elements are included in the tab order, by default, then regardless of
> what
> > browser an AT user has they will get get this content. Regardless of what
> > relationship any interactive content has to the canvas content, keyboard
> > only users will be able to tab into and interact with focusable elements.
> >
> > So for example if I am a keyboard only user and encounter  a canvas
> element
> > that includes a link or 2 links or many that are not associated with the
> > displayed canvas, because they are "fallback" then focus will be lost to
> the
> > users,  end result= confusion
>
> Is this because the AT doesn't support the canvas element yet? I would
> think that it is expected of AT that supports HTML5 markup to ignore
> "fallback" on an element that only applies to legacy browsers.
>
> Or even stronger: the browser that supports the canvas element should
> not make the fallback content available, or accessible through the tab
> order. If it is I would regard that as a bug in the browser
> implementation, no?
>
> I actually just tested this in Firefox 3.7a2pre on a video element.
> The fallback content - even if it has a link (a element) and a
> tabindex on the link - doesn't become part of the tab order. I would
> think that the canvas is working the same way, or should, if one of
> the browsers hasn't implemented it this way yet.
>
>
> > or  I am an AT user accessing the page *using* Firefox, I encounter the
> > message "your browser does not support canvas get Firefox" end
> > result=confusion.
>
> This is what I don't understand. If it is a modern Firefox, then this
> message should not ever be displayed, not on screen and not to AT. Can
> you explain?
>
> Thanks for helping me understand.
>
> Best Regards,
> Silvia.
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html