Re: html5 editor responds to Canvas accessibility related bugs

Ian, Charles,

Maps will in most cases be addressed by alternative content. David Singer
and I have a proposal we have been working on regarding media queries. Maps
are inherently very visual and require alternative ways for interacting
with them for some users such as those who are blind. This problem is not
specific to <canvas>

We are looking to extend media queries that will allow a user to specify in
the browser that they require content that will interoperate with assistive
technologies - for example. We have a number of strategies we are working
on to deal with many of the examples you are referring to being worked on
in IBM and a diagrams project outside of IBM. The think map can be
addressed using the canvas subtree DOM - mainly using ARIA features like
aria-flowto.

What we are trying to do here is address applications that can be made
directly accessible as would typical desktop solutions through *existing*
platform accessibility APIs.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Ian Hickson <ian@hixie.ch>
To:	Charles Pritchard <chuck@jumis.com>
Cc:	Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>,
            "public-canvas-api@w3.org" <public-canvas-api@w3.org>
Date:	10/07/2010 10:14 PM
Subject:	Re: html5 editor responds to Canvas accessibility related bugs
Sent by:	public-canvas-api-request@w3.org



On Thu, 7 Oct 2010, Charles Pritchard wrote:
> On 10/6/2010 12:16 AM, Benjamin Hawkes-Lewis wrote:
> >
> >     * Wordle : http://benjamin.smedbergs.us/wordmap/wordmap.html
> >     * Mind map : http://think-app.appspot.com/
> >     * Names and dates in a genealogical tree :
http://bencrowder.net/blog/2009/10/pedigree-chart-using-html5/
> >     * Labels in diagrams : http://diagramo.com/
> >
> > These probably do involve text editing, but one could easily imagine
> > non-editable versions, which would still benefit from caret navigation
> > and selection.
>
> Ian, are any of these sufficient, do we need more use cases?

In what sense are these use cases? I tried to poke around at each one, but
none of them seemed to do anything that would require caret or selection
APIs. In fact, none of them seemed to even do the most basic things to
make their canvases accessible. Only two of them allow the user to
interact with the text, as far as I can see; in both cases, the text
editing is fully accessible as is and requires no new API to be made
accessible. If anything, I'd say these are an indication that authors are
satisfied enough with the editing features that already exist in HTML
that they don't feel the need to reimplement them manually.

I would also add that given that the <canvas> parts of these pages are
completely inaccessible currently, not even using the most basic features
we've provided to make such pages accessible, it is rather premature to
consider what we could do to help them make their pages accessible if they
were to decide to switch from using the existing simple text editing
features to building their own from scratch.

In any case, as I've said before: if someone can come up with a way to
make an API for these features that addresses the needs I listed (which,
based on past experience with accessibility APIs, would likely be the
minimum necessary to actually improve accessibility on the Web for pages
whose authors write their own editors), and assuming that browsers would
be willing to support them, then there's no question that we'd add them to
the spec. I just don't think that working on such an API is the most
time-efficient way of improving the Web platform's accessibility story. We
could improve life for users of ATs faster by working on other things.

There is an opportunity cost to working on any one feature. If feature A
improves the life of one million AT users and takes one man-month, and
feature B improves the life of two million AT users and takes one
man-month, then a world in which we work on feature A before feature B has
more disenfranchised users than a world in which we work on feature B
before feature A.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'