Re: Please vote on the canvas accessibility proposal

On Wed, 24 Feb 2010 15:53:29 +0100, Richard Schwerdtfeger  
<schwer@us.ibm.com> wrote:


>> Silvia Pfeiffer <silviapfeiffer1@gmail.com>
...
>> Assuming we have a very clever AT that interprets a canvas, could it
>> make it accessible without any further (or only little extra) hints?
>>
>> Meaning: is the ability of being accessible really a function of the
>> author? Or rather a function of the actual markup of the canvas
>> combined with the capabilities of my AT? If it is the latter (and
>> that's my understanding), then marking the canvas with an attribute
>> that states that the canvas is accessible is not useful: only if my AT
>> is capable of making it accessible will it really be accessible.
>>
> Silvia, the problems are that:
>
> - A test tool needs to assess if canvas is accessible. As is it is not
> today.

But how does adom provide that? It may be that a canvas is accessible by  
having an image map. It may (in the trivial case like hixie's little  
picture) be possible to make it accessible without even having a map. But  
having an adom only means "the author made some claim that this *might* be  
accessible".

Having seen lots of pages get a DOCTYPE because some testing tools simply  
checked for that and claimed that the page passed the validity requirement  
of WCAG 1, and seen lots of rubbish alt text for the same reason, I don't  
think that we score any wins by going down this path. If you want to claim  
your content is accessible, why not add a bit of RDFa that explicitly says  
why?

> - A test tool needs to know what content to assess if it is to be made
> directly accessible.

The script that runs the canvas - what it paints and how it informs the  
user, and what input actions it accepts, and what they do.

> - A browser needs to map an accessibility implementation to the
> accessibility API to work.

Sure, but I believe that adom is unnecessary for this purpose.

> - We have been asked to try to make <canvas> directly accessible where
> possible without having to use alternative renderings as a blind or
> mobility impaired user may want to sit side by side each other to use the
> same visual application.

Yes, this is definitely a goal.

> - With HTML 5 we are STUCK with having to deal with fallback content
> (content that runs if you don't support all the HTML 5 features). This
> content MAY have no correlation to what is being rendered even though it
> may be accessible. Try to imagine navigating the Bespin editor and the
> fallback was a plug-in for emacs or some other editor where where you  
> have different toolbars and a different text editor and the keyboard  
> navigation did not line up. As a sighted user I would be screaming. In
> this case you would need to render the alternative content entirely.

Sure, but there are other ways around this problem. Using a completely  
invisible map, with a structure described in aria, means you don't see it  
if you don't render the canvas. Using a map containing block content means  
you can re-use the relevant pieces.

So the use case for adom seems to boil down to a test of whether the  
canvas or its fallback content is rendered, in order to provide different  
user interaction, and the attribute seems instead to force an author to  
provide either accessibility or a fallback - which doesn't strike me as a  
sensible dichotomy to force.

...
> 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. When it is set to true a
> test tool can analyze the subtree of canvas for accessibility and the
> browser can include the subtree in the navigation order and map it to the
> accessibility API. adom can be computed by web applications simply by
> assessing if the browser supports canvas and if it can create a direct
> mapping in the subtree to represent canvas. This is EXTREMELY important.

But using an image map allows for this, and *also* allows for the controls  
to be outside the canvas, enabling a cascade of fallbacks to use the same  
controls if you really want to, or for them to be hidden inside the canvas  
yet navigable and interactive. All without writing a line of new code or  
teaching anyone anything new, which is a bonus.

> So, this is why adom is so important. Without some indication to the
> browser or a test tool of what is the accessible representation we are
> casters up. adom is NOT an accessibility compliance statement.

No. But a tool can check aria attributes on the canvas, and usemap. That  
shows something was done. More than that and you have to start analysing  
codepaths - which is possible (in the real world if not in the theoretical  
general case) to see whether there are corresponding ways to initiate them  
without a mouse, and to see if there is some feedback to the user that  
doesn't rely on (but mirrors meaningfully in some way) the painting of the  
canvas itself.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Wednesday, 24 February 2010 15:58:05 UTC