Re: Fw: canvas accessibility progress

Hi.

For the record: I find Rich's suggestion reasonable. Also I have some
implementation related notions.

Shadow content should be exposed to AT only and it should have normal
accessible objects having x and y coordinates, width and height and it
should be possible to find them by hit test. They should expose visible
state if they are not marked as invisible explicitly (for example
aria-hidden="true"). Geometrically these accessible objects should be
restricted by canvas bitmap. If shadow content size is greater than canvas
bitmap then the content should be be scrollable. If text inside of shadow
content is styled then styles should be exposed via AT API (for example, via
IA2 text attributes).

If shadow content has control elements or editable areas where tab
navigation is applicable then canvas bitmap author should process tab key
press and use aria-activedescedant to point on "focused" element as long as
he change "focus" location inside of canvas bitmap. For example, if canvas
renders buttons then focused button should be visually marked (dotted border
and etc) and canvas should have aria-activedescedant attribute pointing to
the button from shadow content (this could be either HTML button or ARIA
button).

You're feedback is welcome.

Thank you.
Alex.


On Tue, Nov 3, 2009 at 10:37 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> Hi Alex,
>
> Sure, you can site me. Or you can point me to the bugzilla defect and let
> me comment. Whichever works.
>
> In the default view the canvas view should be rendered with the
> accessibility tree exposed to the AT. In this case we have
> aria-activedescendant operable on the canvas element to allow the script
> writer to control focus within canvas. I can see where tab navigation could
> be an issue for canvas. One suggestion would be to allow for the user to
> navigate in and out of the shadow DOM with the keyboard much the same way we
> do plug-ins for Java or Flash. This way we don't disrupt the normal tab
> cycle. Once "in the shadow DOM" tabbing is confined to within the shadow
> DOM. I need to look back at the use cases on canvas accessibility wiki.
>
> I like your idea of binding switching views through accesible actions. That
> would be slick. If we do that we should allow the optional view include an
> optional description via say the title attribute. ... just a suggestion or
> an aria-describedby property to support the accessibility API.
>
> Absolutely we can open the conversation up. I cc'd the public canvas list
> serve on the W3C, Janina, and Sam Ruby. Feel free to include whoever you
> like.
>
> Rich
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
>
> [image: Inactive hide details for Alexander Surkov ---11/02/2009 09:50:19
> PM---Hi, Rich. Can I cite you on mozilla's bugzilla if necess]Alexander
> Surkov ---11/02/2009 09:50:19 PM---Hi, Rich. Can I cite you on mozilla's
> bugzilla if necessary?
>
>
>     *Alexander Surkov <surkov.alexander@gmail.com>*
>
>             11/02/2009 09:47 PM
>
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
> cc
>
>
> Subject
>
> Re: Fw: canvas accessibility progress
>
> Hi, Rich.
>
> Can I cite you on mozilla's bugzilla if necessary?
>
> I think tab navigation in shadow tree can make hear attack for any sighted
> user, for example developers who uses tools enabling accessibility (in
> instance, Mozilla DOM Inspector used by non a11y developers which has
> abilities to inspect a11y tree). Also I'm sure Firefox users could find easy
> implicit way to enable accessibility (for example, they can install firefox
> extension which uses accessibility for its needs) and users might not know
> about this. So users can enable accessibility not on their demand and they
> got broken tab navigation from their point of view. Therefore I think tab
> navigation inside of shadow tree is not only hard-to-implement thing, it's
> the thing which can confuse sighted users. Therefore aria-activedescedant
> approach is nicer from this point of view. However it makes impossible
> normal life of AT users in the case when canvas shadow tree would have tab
> navigable controls. The best approach I can think of is screen readers
> should be changed to support this. For example, if we'll change IA2 to
> provide methods to get next/previous accessibles in tab navigation order.
> Dunno.
>
> But I like your idea to switch canvas view. And as you noticed we don't
> required to force web page authors to implement buttons allowing to change
> the view. We could easy to expose accessible actions so that AT users could
> change the view when they want.
>
> However you consider view idea within an ability to expose shadow tree to
> AT. And I have more questions than answers how to implement shadow
> accessible tree (for example, tab navigation problem). Nevertheless could we
> change this idea to get rid this? For example, if there is no @view
> attribute then canvas bitmap is rendered, if @view="default" then shadow
> tree is rendered for all users and etc. From implementation point of view we
> shouldn't dig into trick mozilla layout implementation and don't need to
> rape mozilla layout guys to make shadow tree accessible. As well it will
> hurt neither sighted users nor blind users by tab navigation problems. What
> do you think?
>
> Can we cc more people to our discussion?
>
> Thank you.
> Alex.
>
>
> On Fri, Oct 30, 2009 at 10:28 PM, Richard Schwerdtfeger <*
> schwer@us.ibm.com* <schwer@us.ibm.com>> wrote:
>
>    Hi Alex,
>
>    We are going to need 3. We will need to have aria-activedescendant work
>    too. Apple expressed an interest to have tabindex work as well in the shadow
>    DOM but that creates the focus rendering issue. Will the Mozilla team have a
>    heart attack over that?
>
>    So, here are my thoughts for the Mozilla team skeptics: Canvas is a
>    brand new paradigm shift for the Web. Canvas needs to be considered the view
>    and a rendering representative of the model that backs it. SVG is going to
>    have similar issues going forward. We need to do the prototyping to vet out
>    the issues before we impact the HTML or Canvas specification. So, we need to
>    work together. What I would do for now is simply disable all rendering of
>    child content now for option 3 - including keyboard focus for the child
>    content. It should be up to canvas to do that. We should also consider doing
>    the following long term:
>
>    <canvas view="">
>    <div> ...
>    </canvas>
>
>    where the value of view is:
>
>    default: use the default canvas view and depend on child content for
>    accessibility (what we are doing now)
>    textmodality: This is a text alternative rendering for a complex
>    visualization: Example use case: grid alternative to a 2D graph. driving
>    direction alternative to a map.; a closed caption version of a video
>    audiomodality: audio equivalent to visual view.
>
>    An AT or script author could change the property could then switch the
>    view
>
>    Something like:
>
>    <canvas view="">
>    <defalult> (this is un-rendered)
>    <div role="document">
>    ....
>    </div>
>    </default>
>    <textmodality>
>    <div role="grid">
>    <div role="row">
>    <div role="gridcell" tabindex="0">
>    ...
>    </textmodality>
>    <audiomodality>
>    ...
>    </canvas>
>
>
>
>    Rich Schwerdtfeger
>    Distinguished Engineer, SWG Accessibility Architect/Strategist
>
>    [image: Inactive hide details for Alexander Surkov ---10/30/2009
>    01:21:54 AM---Hi, Rich. I got some discussion with Mozilla layout folk]Alexander
>    Surkov ---10/30/2009 01:21:54 AM---Hi, Rich. I got some discussion with
>    Mozilla layout folk (
>         *Alexander Surkov <**surkov.alexander@gmail.com*<surkov.alexander@gmail.com>
>                            *>*
>
>                            10/30/2009 01:20 AM
>                                 To
>
>    Richard Schwerdtfeger/Austin/IBM@IBMUS
>    cc
>    Subject
>
>    Re: Fw: canvas accessibility progress
>    Hi, Rich.
>
>    I got some discussion with Mozilla layout folk (*
>    https://bugzilla.mozilla.org/show_bug.cgi?id=495912*<https://bugzilla.mozilla.org/show_bug.cgi?id=495912>
>    ).
>
>    There are few options we can follow to make canvas accessible:
>    1) Render canvas child content within canvas bitmap
>    2) Render canvas child content only
>    3) Render canvas bitmap only and expose canvas child content to AT.
>
>    1) and 2) options might be controlled by special preference settings in
>    Firefox if we'll find them appropriate. In my opinion 3d option should be
>    the best because users don't need to play with preferences and sighted users
>    don't see canvas child content when proposed preference is switched on.
>    However it's a bit longer way and harder to implement. On the another hand
>    if I get right our layout gurus are a bit sceptic to spend their time to
>    discuss implementation details for the things wich aren't in the spec and
>    especially if we were asked to have a pilot version only. So for the first
>    approaching I could write small extension that will insert canvas child
>    content into the DOM and therefore it will become accessible. One things
>    that bothers me it's completely different from 3d option and therefore, for
>    example, it can't demonstrate focus management via aria-activedescedant.
>
>    What do you think?
>
>    Thank you.
>    Alex.
>
>    On Thu, Oct 29, 2009 at 10:42 PM, Richard Schwerdtfeger <*
>    schwer@us.ibm.com* <schwer@us.ibm.com>> wrote:
>       Hi Alex,
>
>          As a general strategy, browsers like FF will need to consider
>          having the accessibility object model a reflection of what is not visible
>          for technologies like SVG and canvas. When I brought ARIA to W3C the intent
>          was to leverage the existing visible DOM as it is very much like today's
>          GUIs. This will support HTML markup for a very long time. Yet, SVG and
>          canvas are different animals. Here, your model is more like a collection of
>          drawing primitives. Our solution needs to be one where we either:
>
>          1. provides an accessibility tree (hidden as you point out) bound
>          loosely to what is being drawn and makes use of ARIA 1.0
>          2. provides for an accessibility API bound to these objects
>          (longer term). Will require an ARIA 2.0 approach allowing for customization
>          3. allows for equivalent alternative content
>
>          So, for now we need to address 1 which you are doing. This should
>          be adequate to support Bespin but not say 3D graphics.
>
>          I look forward to your canvas child content approach. This is in
>          line with what we have been discussing.
>
>
>
>          Rich
>
>
>          Rich Schwerdtfeger
>          Distinguished Engineer, SWG Accessibility Architect/Strategist
>
>          [image: Inactive hide details for Alexander Surkov ---10/29/2009
>          04:57:36 AM---Hi, Rich. Thank you for an example.]Alexander
>          Surkov ---10/29/2009 04:57:36 AM---Hi, Rich. Thank you for an example.
>
>
>
>           *Alexander Surkov <**surkov.alexander@gmail.com*<surkov.alexander@gmail.com>
>                                                 *>*
>
>                                                 10/29/2009 04:57 AM
>
>  To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
> cc
> Subject
>
> Re: Fw: canvas accessibility progress
>
>
>          Hi, Rich.
>
>          Thank you for an example.
>
>          Since accessibility in Firefox depend a lot on layout, for
>          example, we create HTML accessibles based on layout rather than DOM then we
>          could fix the code to create accessible objects based on DOM if the HTML
>          content is inside of canvas. This a hack but it shouldn't be hard to
>          implement. However since DOM nodes inside of canvas aren't rendered
>          therefore created accessible will have invisible state which will prevent AT
>          to work with them I think. Though I guess it could be fixed as well by more
>          or less hack way.
>
>          On the another hand I think theoretically there is another option
>          which is to render hidden canvas child content in memory. However I don't
>          have any clue how hard to implement this. Though obviously it should be more
>          correct way because we could expose styling and etc to AT in this case.
>
>          However if we will think about things like Bespin where editor is
>          required then I'm not sure either way could be powerful. For example,
>          editor's clipboard operations aren't work until editor is focused. I would
>          guess we can't set focus in either approach. I think it should be more
>          powerful way is to provide JS interfaces to allow accessible object creation
>          in JS. I agree DOM-based approach should fit greatly for simple examples
>          like your one. But it seems to me it's needed something more powerful in the
>          case of Bespin-like stuffs.
>
>          Please give me a couple of days to clarify an idea with canvas
>          child content rendering in memory.
>
>          Thank you.
>          Alex.
>
>
>          On Wed, Oct 28, 2009 at 11:29 PM, Richard Schwerdtfeger <*
>          schwer@us.ibm.com* <schwer@us.ibm.com>> wrote:
>              Alex,
>
>                      This is an fyi. Attached is a sample for you to
>                      check.
>
>                      Rich
>
>
>                      Rich Schwerdtfeger
>                      Distinguished Engineer, SWG Accessibility
>                      Architect/Strategist
>                      ----- Forwarded by Richard Schwerdtfeger/Austin/IBM
>                      on 10/28/2009 10:28 AM -----
>                                        *Richard Schwerdtfeger/Austin/IBM*
>
>                                                                                                                      10/28/2009
>                                                                                                                      10:10 AM
>
>                      To
>
>                      Frank Olivier <*franko@microsoft.com*<franko@microsoft.com>>,
>                      "*public-canvas-api@w3.org*<public-canvas-api@w3.org>"
>                      <*public-canvas-api@w3.org*<public-canvas-api@w3.org>
>                      >
>                      cc
>
>                      Sam Ruby/Raleigh/IBM@IBMUS, *janina@rednote.net*<janina@rednote.net>,
>                      Laura Carlson <*laura.lee.carlson@gmail.com*<laura.lee.carlson@gmail.com>
>                      >
>                      Subject
>
>                      canvas accessibility progress    Frank sent me a
>                      sample of canvas with a shadow DOM which I added aria live region support
>                      for. The shadow DOM is exposed in the actual DOM but a screen reader cannot
>                      speak it becuase it is not exposed to the accessibility API. This is due to
>                      the fact that it is hidden.
>
>                      So, the next step is to expose the shadow DOM. Alex
>                      Surkov is giving me a time for when he can have a test patch that:
>
>                      - exposes the shadow DOM to the accessibility API
>                      - supports aria-activedescendant on canvas. This will
>                      allow the canvas author to triger focus change events in the shadow DOM by
>                      simply modifying the active id in the canvas element. This is low impact on
>                      the browser rendering engine because they don't have to draw anything.
>
>                      Frank, as soon as I get a patch or test build I will
>                      tell you how to get it. Attached is my updated sample.
>                      *
>
>                      (See attached file: canvas-acc.html)*
>
>
>                      Rich
>
>                      Rich Schwerdtfeger
>                      Distinguished Engineer, SWG Accessibility
>                      Architect/Strategist
>
>
>
>
>