Re: Please vote on the canvas accessibility proposal

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote on 02/24/2010 05:35:00
PM:

> Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> 02/24/2010 05:35 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> 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
>
> Subject
>
> Re: Please vote on the canvas accessibility proposal
>
> 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.
>
Silvia,

The usemap approach does not allow the author to use standard HTML element
and it requires the author to spend a tremendous amount of time adding
semantic markup to the content to provide the hierarchical structure
provided by the DOM. Here is an example:>

<tree>
  <group>
    <treeitem>meat</treeitem>
       <group>
             <treeitem chicken>
             <treeitem beef>
       </group>
    </treeitem>
    <treeitem>baz<treeitem>>
  </group>
</tree>

a Sighted user an see this information on the screen but it is the
structural markup that makes this easy for authors. The author could
populate all the parent nodes with aria-owns but this is a LOT more work.
I get this for free in the DOM. A blind user gets the fact that chicken is
in the meat group because of this hierarchy.

Also, HTML has a lot of standard controls which are already accessible that
could be used in the shadow DOM.

I believe the opera approach is great for many implementations but let's
not make this harder for the author. The Opera approach has limitations. We
already have an accessibility problem with canvas.

>
> > 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.
>

Silvia, For the 12th time now. adom is not a statement of accessibility. It
simply says to use the subtree as the accessibility mapping as intended by
the author. It is NOT  A COMPLIANCE STATEMENT. It is a way for the author
to associate their subtree of canvas as their accessibility implementation
of canvas.

I need you and Ian to point me to the text in the proposal that makes the
claim you are both making.

> accessibility. What if the Web developer thinks they have made the
> subtree accessible, but have in fact forgotten to add aria attributes

What if they forget to do this in the areamap example? What if they forget
to do this elswhere in the document?

Ian's example was a non-interactive picture on the web page. This about the
most trivial accessibility issue to address. Are you trying to tell
everyone that <canvas> is going to be used to create non-interactive
pictures most of the time? If that is the case I would suggest dumping it
from HTML 5.

> 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.
>
Exactly, and it needs to know what part of the web page to test. That is
all adom is doing for the test tool.

>
> Anyway - just my 2c as an curious onlooker (and hoping we won't run
> into similar issues with media elements).
>
> Cheers,
> Silvia.