Re: canvas accessibility progress

David,

The default for canvas is to navigate the subtree. The proposal was for the
-nonav attribute to skip it. Frankly, I don't see a lot of people using the
fallback content in canvas. The major HTML 5 browser vendors are supporting
canvas and given the increase in memory and processor speeds on mobile
devices is making the need for having the fallback content actually used
for "fallback" content is less important. This, I believe, is why Machiej
pushed to have keyboard navigation turned on in the subtree be the default
behavior.

I am not concerned that keyboard navigation goes through the canvas subtree
for "fallback" content that does not bind. HTML 5 does not reach last call
until next April (at the earliest). By the time HTML 5 becomes a
recommendation the need for fallback will be moot as I see it.

The adom proposal was rejected as people did not want navigation of the
subdom for accessibility alone. Instead we have a -nonav proposal which you
signed off on.

As for the default indication of keyboard focus and caret/selection
tracking we have proposals out to drive magnification:

- That provide an API to do this in the Canvas 2D API which is in limbo at
the moment
- That provide an API to do this in a DOM extension (Apple proposal). We
will discuss this on the Monday ARIA Call along with the DOM 3 events
proposal.
- That uses an image map to overlay the canvas but which also depends on a
call to drive focus/caret selection where the normal image map does not
suffice

The author still has to draw visual focus on the canvas. Think of this as
an MVC architecture.

Rich Schwerdtfeger
CTO Accessibility Software Group



From: David Bolter <david.bolter@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Sam Ruby/Raleigh/IBM@IBMUS, Paul Cotton
            <Paul.Cotton@microsoft.com>, janina@rednote.net,
            public-canvas-api@w3.org, franko@microsoft.com
Date: 09/23/2010 09:26 AM
Subject: Re: canvas accessibility progress
Sent by: public-canvas-api-request@w3.org



I have concerns about the "Some Potential Issues" section:

- begin quote -
      Where content is currently included in canvas, it is almost
      exclusively of the “get a better browser that supports canvas”
      variety, so screen reader users will likely encounter this when using
      IE9.
      Authors will most likely continue to provide useless information (for
      screen reader users) as the concept of “fallback content” in the
      HTML5 specification is not a suitable concept of what canvas content
      is for keyboard and AT users in browsers that support the canvas
      element.
      keyboard focus is lost if interactive elements are included inside
      the canvas, because while elements inside the canvas element are
      focusable by default, there is no corresponding default indication of
      focus to identify where current focus is.
- end quote -

Did we come up with an attribute for 'this subtree is actually useful for
keyboard and AT'?

cheers,
David

On 21/09/10 12:41 PM, Richard Schwerdtfeger wrote:


      Sam, Paul, Janina,

      It looks like Microsoft has implemented the canvas keyboard navigable
      subdom proposal as part of our canvas accessibility proposal in IE 9.
      Now we just need to get the focus tracking and caret tracking issues
      resolved:

      http://www.paciellogroup.com/blog/?p=670



      Nice work Frank!

      David, has this much been implemented in Firefox 4? That would give
      us two implementations of the navigable subdom.

      Rich

      Rich Schwerdtfeger
      CTO Accessibility Software Group