- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 3 Nov 2009 08:37:45 -0600
- To: Alexander Surkov <surkov.alexander@gmail.com>
- Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>, Sam Ruby <rubys@us.ibm.com>, janina@rednote.net
- Message-ID: <OFD5D03C97.FA41ED7F-ON86257663.004EE8CD-86257663.00505C43@us.ibm.com>
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
Alexander Surkov
<surkov.alexander
@gmail.com> To
Richard
11/02/2009 09:47 Schwerdtfeger/Austin/IBM@IBMUS
PM 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>
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
Inactive hide details for Alexander Surkov ---10/30/2009 01:21:54
AM---Hi, Rich. I got some discussion with Mozilla layout folkAlexander
Surkov ---10/30/2009 01:21:54 AM---Hi, Rich. I got some discussion with
Mozilla layout folk (
Alexander Surkov
<?
surkov.alexander@
gmail.com>
To
10/30/2009 01:20 Richard
AM Schwerdtfeger/Aust
in/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).
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> 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
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>
10/29/2009 04:57 AM
To
Richard
Schwerdtfeger/Au
stin/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> 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 -----
Richar
d
Schwer
dtfege
r/Aust To
in/IBM
Frank Olivier
<?
10/28/ franko@microso
2009 ft.com>, "?
10:10 public-canvas-
AM api@w3.org" <
public-canvas-
api@w3.org>
cc
Sam
Ruby/Raleigh/I
BM@IBMUS,
janina@rednote
.net, Laura
Carlson <
laura.lee.carl
son@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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic27773.gif
- image/gif attachment: ecblank.gif
Received on Tuesday, 3 November 2009 14:38:48 UTC