W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2011

Re: Working Notes: 2011-01-23 Canvas Accessibility Working Group

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Mon, 24 Jan 2011 08:48:43 -0600
To: Charles Pritchard <chuck@jumis.com>
Cc: dmazzoni@google.com, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org
Message-ID: <OFC1C4AD08.40D3E8B3-ON86257822.00514B6A-86257822.00515DE0@us.ibm.com>


Is it IE9's focusRing implemented via our changes to it or the existing


Rich Schwerdtfeger
CTO Accessibility Software Group

From:	Charles Pritchard <chuck@jumis.com>
To:	"public-canvas-api@w3.org" <public-canvas-api@w3.org>
Cc:	Richard Schwerdtfeger/Austin/IBM@IBMUS, dmazzoni@google.com
Date:	01/23/2011 07:39 PM
Subject:	Working Notes: 2011-01-23 Canvas Accessibility Working Group
Sent by:	public-canvas-api-request@w3.org

Current agenda:

"form a task force ... that will result in canvas content being natively

"Should we add a caret location API to canvas, or is the focus API

"This is for the purposes of driving screen magnification"

"scrolling into view as content consumed and presented to user"

"This is solely for magnifier tracking."

Current issue:

Used in combination, the rectangle (setCaretSelectionRect) and focus
area (drawFocusRing)
enable inline scrolling akin to [input type="text"]. There is
significant opposition to text editing in canvas.

This side effect can not be helped: magnification requires scrolling
content into view.
Supporting magnification AT is an important step in "canvas a11y".

Last meeting:

We reached consensus on " context . drawFocusRing(element) " as an
improvement to the present whatwg draft.

Ian Hickson originally published drawFocusRing with four arguments:
" context . drawFocusRing(element, x, y, [ canDrawCustom ]) "

"canDrawCustom" was dropped, as redundant and problematic.
"x, y" now defaults to the centroid of the polyline / the center of the

drawFocusRing has been successfully demonstrated in IE9 preview releases
with the JAWS screen reader.
Congratulations Microsoft IE Team!

Current work:

We're presently discussing a new method, intended to assist magnifiers:
" context . setCaretSelectionRect(element, x, y, w, h) "

The primary purpose of this function is to pass indicators to the AT to
enable canvas a11y screen magnification.
We may remove references to "text", as they may 'encourage' canvas-based
text fields.

There are many uses for text selection, and caret positioning, in
Canvas-based interfaces, and many have
been discussed while looking at this method. Should this method have
another name, does it matter?

setCaretSelectionRect may trigger various roles, depending on the
implementation and element passed.
Is the name a major issue; if it's not, what about the functionality?

With focus ring, the magnifier AT is  informed both of the outlined area
of the focused element,
as well as the inlaying area which the keyboard is presumably engaging.

This additional point of data assists the magnifier, with minimal cost
to UA implementers.


Mapping in IAccessible2 and MSAA:

"MSAA is ... able to communicate the necessary caret tracking
information to Input Panel without the caret showing"
setCaretSelectionRect maps to CreateCaret and SetCaretPos
GetCaretBlinkTime is another mapping


Accessibility, canvas and the scripting environment:

There is an archive available of progress within the w3c:

T.V Raman posted an introduction to ARIA concepts in scripting
"Now, turning to the canvas and SVG issue ... think of the tuple
(aria-role, aria-state) as additional opcodes...
We can build higher-level abstractions above this assembly language in
order to produce meaningful feedback to the end-user"

Feedback on text fields in canvas a11y:

Ian Hickson worries that caret location "might encourage ... use ... for
text fields".

David Bolter will be "evangelizing against" (demonizing) "canvas for
text editing",

Oliver Hunt is "opposed to APIs that attempt to make it possible to
create editors using canvas...
any attempt is simply going to result in a half-assed API"

Frank Olivier reports: "the IE team does not think that text editing via
canvas is a problem that we should tackle for HTML5"

Richard Schwerdtfeger notes "even if Rich Text Editing is not supported,
at this time, we will need to support a caret and focus ring"

(image/gif attachment: graycol.gif)

Received on Monday, 24 January 2011 14:49:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:52 UTC