- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 25 Feb 2010 10:35:00 +1100
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Ian Hickson <ian@hixie.ch>, Steven Faulkner <faulkner.steve@gmail.com>, public-canvas-api@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, public-html-a11y-request@w3.org
On Thu, Feb 25, 2010 at 2:08 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > >>> Ian Hickson <ian@hixie.ch> >> Sent by: public-html-a11y-request@w3.org >> >> The one <canvas> I use on a regular basis (not a demo) has accessible >> fallback and no adom="" attribute. Which is more common is essentially >> impossible to tell from purely anecdotal evidence. >> >> http://www.whatwg.org/issues/data.html?period=1 >> Seeing this example and comparing it to the spec at http://dev.w3.org/html5/2dcontext/#focus-management makes me wonder if we are in fact dealing with two different types of accessibility information for <canvas>: * there is canvas accessibility information (like in Ian's example) that can easily stand by itself if the canvas is not rendered, i.e. it will also work in legacy browsers as fallback content * there is canvas accessibility information (like the example in the Focus Management section) that is not relevant to be displayed without the canvas, i.e. it is not relevant fallback content In Ian's example, there is basically no difference between fallback content and accessibility replacements for <canvas>. Therefore, it is easy to add it inside the <canvas> as fallback and at the same time let it be available for AT. (maybe with the added improvements recommended by Richard). However, where the accessibility information doesn't make sense to be also fallback - namely when drawFocusRing is used, which only makes sense when the <cavas> is actually displayed - there is no means to decide for a legacy browser if this should be displayed or not. The proposed <usemap> seems to make a lot of sense in this situation. Then anything outside the <usemap> element can continue to be fallback content, but the stuff inside <usemap> is just for accessibility information. > adom basically says, as in the proposal, that if it is set to use the > <canvas> subtree (between the start and end canvas tags) as the accessible > representation of what is being drawn on canvas. I am skeptical about absolute statements like this. To me, accessibility is not a boolean - there are many shades of accessibility. What if the Web developer thinks they have made the subtree accessible, but have in fact forgotten to add aria attributes and such? Or take Ian's example - Ian thought his example was accessible, but you pointed out how it could still be improved. I am under the impression that most of the time that is a typical situation. I think a tool that needs to evaluate whether something is accessible cannot rely on an attribute but has to do the hard work of actually walking through the DOM tree and identifying whether there is actual effort done in providing accessibility markup. Anyway - just my 2c as an curious onlooker (and hoping we won't run into similar issues with media elements). Cheers, Silvia.
Received on Wednesday, 24 February 2010 23:35:57 UTC