Re: Please vote on the canvas accessibility proposal

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-html-a11y-request@w3.org wrote on 02/22/2010 10:13:24 PM:

> Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> Sent by: public-html-a11y-request@w3.org
>
> 02/22/2010 10:13 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS>
>
> cc
>
> cyns@exchange.microsoft.com, Andi Snow-Weaver/Austin/IBM@IBMUS,
> janina@rednote.net, jongund@uiuc.edu, cooper@w3.org, David Bolter
> <david.bolter@gmail.com>, Steven Faulkner
> <faulkner.steve@gmail.com>, Frank Olivier <franko@microsoft.com>,
> public-html-a11y@w3.org
>
> Subject
>
> Re: Please vote on the canvas accessibility proposal
>
> I am not going to vote on this because I haven't been involved in the
> discussion and it's not my area of expertise.
>
> But I have tried to follow the discussion in the meeting minutes etc.
> so I have a few questions.
>
> 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.
- A test tool needs to know what content to assess if it is to be made
directly accessible.
- A browser needs to map an accessibility implementation to the
accessibility API to work.
- 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.
- 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.

> Or in other words: I as a Web page author can only do my best to try
> and mark up everything I can to help AT make things accessible. I
> cannot ultimately decide whether something is accessible or not for
> all combinations of browser/AT of a user.
>
> Given this understanding, to me, the attribute honestly doesn't make
> much sense. I am rather interested what extra markup we introduce for
> canvas that will help AT make a canvas accessible. Then, if such
> markup is available, and depending on how complete it is, my canvas
> will be more or less accessible. A binary proposition on whether
> something is accessible seems not very useful IMO, but I may be wrong
> and misunderstand.
>
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.

Currently, the canvas subtree can be anything.

So, what the author would do in the subtree (if canvas were true) would use
a combination of standard HTML elements, contenteditable areas, and ARIA to
build a structurally accurate representation of the conceptual interactive
visual elements on canvas. The browser would map this to the platform
accessibility API for a screen reader to use it. The author would make use
of new Canvas 2D API, in the works, to render focus position and caret
position on the canvas so that a magnifier or can follow user keyboard
input and convey point of regard to all sighted users.


If the author cannot provide a directly accessible rendering of canvas
he/she may render the fallback content, as an option, to users in which
case canvas would be hidden and the accessibility test tool can analyze the
newly rendered accessibility tree for the alternative content. The author
can also render any other content in the place of <canvas> should this be
desired.

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.



> Best Regards,
> Silvia.
>
>
> On Tue, Feb 23, 2010 at 11:00 AM, Richard Schwerdtfeger
> <schwer@us.ibm.com> wrote:
> > http://www.w3.org/2002/09/wbs/44061/20100225_canvas/
> >
> > Thank you,
> > Rich
> >
> >
> > Rich Schwerdtfeger
> > Distinguished Engineer, SWG Accessibility Architect/Strategist
>