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

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

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 23 Jan 2011 17:36:58 -0800
Message-ID: <4D3CD7BA.5000501@jumis.com>
To: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
CC: Richard Schwerdtfeger <schwer@us.ibm.com>, dmazzoni@google.com
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 environments:
"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"
Received on Monday, 24 January 2011 01:37:29 UTC

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