Re: Please vote on the canvas accessibility proposal

Hi Sylvia,

>At this point, I actually wonder if the Canvas' fallback content is
>not overloaded in meaning: it can both contain information for legacy
>browsers and it can contain focusable elements for accessibility
>reasons. I wonder if it would make sense to separate the two concepts
>somehow. Maybe some markup that would be invisible on screen if the
>canvas element is supported, but can still be accessed by the AT?
>Maybe it is possible to move the focusable elements into some other
>subelement of Canvas (similar to how the video element has source
>elements inside it)?
I agree that the concept of the canvas concept being "fallback" does not fit
well and have argued this on other related threads.
But nobody appears to want to tackle this aspect of the issue.

Maybe some markup that would be invisible on screen if the
>canvas element is supported, but can still be accessed by the AT?
Thats what is suggested in the spec now. For focusable content AT's pretty
much just pass the keystrokes to the browser and listen for the response
from the browser (change in state of the object etc), its the browser that
controls the availability of the controls/links etc. chnaging this mdoel
just for canvas does not seem like a good idea.

Note: it is not just AT users that are negativley affected or are the
beneficiaries of providing focusable elements in the canvas subtree, it is
any user that navigates using the keyboard.

regards
steve

On 24 February 2010 07:31, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote:

> Hi Steven,
>
> On Wed, Feb 24, 2010 at 3:44 PM, Steven Faulkner
> <faulkner.steve@gmail.com> wrote:
> > 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.
>
> After having read the URL that you pointed to, it seems to me that
> fallback content in canvas is different to fallback content in video.
>
> This is the relevant paragraph from video
> (
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video
> ):
> "Content may be provided inside the video  element. User agents should
> not show this content to the user; it is intended for older Web
> browsers which do not support video, so that legacy video plugins can
> be tried, or to show text to the users of these older browsers
> informing them of how to access the video contents."
>
> It seems this is different for the Canvas since the canvas fallback
> content can also provide focusable content.
>
> At this point, I actually wonder if the Canvas' fallback content is
> not overloaded in meaning: it can both contain information for legacy
> browsers and it can contain focusable elements for accessibility
> reasons. I wonder if it would make sense to separate the two concepts
> somehow. Maybe some markup that would be invisible on screen if the
> canvas element is supported, but can still be accessed by the AT?
> Maybe it is possible to move the focusable elements into some other
> subelement of Canvas (similar to how the video element has source
> elements inside it)?
>
> Note, I am trying to make suggestions not understanding all the
> consequences, that I am sure you have thought through. However, I have
> the impression that the @adom attribute doesn't actually help you
> separate the overload issue: if @adom is given, the browser would
> still display both, the text for legacy browser and the extra
> focusable elements that at this stage relate to something that the
> browser cannot visually present.
>
> This is also me not knowing how fixed is focus specification part of
> the Canvas http://dev.w3.org/html5/2dcontext/#focus-management is. If
> it is fixed, there may not be a good solution to your problem other
> than expecting Web developers to write a javascript function to
> determine if the canvas is supported and only create the focus
> specification part of the Canvas in cases where the canvas is indeed
> supported.
>
> Best Regards,
> Silvia.
>
>
> >>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
> >
>



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