- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 24 Feb 2010 18:31:52 +1100
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: "public-html-a11y@w3.org" <public-html-a11y@w3.org>, public-canvas-api@w3.org
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 >
Received on Wednesday, 24 February 2010 07:32:46 UTC