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

Current agenda:

"form a task force ... that will result in canvas content being natively 
accessible."
http://lists.w3.org/Archives/Public/public-html/2009Jul/0562.html

"Should we add a caret location API to canvas, or is the focus API  
sufficient?"
http://lists.w3.org/Archives/Public/public-html/2011Jan/0200.html

"This is for the purposes of driving screen magnification"
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0016/HTML_Canvas_2DContext120910.html

"scrolling into view as content consumed and presented to user"
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0010.html

"This is solely for magnifier tracking."
http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0039.html

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.
http://www.w3.org/2011/01/17-html-a11y-minutes.html

Ian Hickson originally published drawFocusRing with four arguments:
" context . drawFocusRing(element, x, y, [ canDrawCustom ]) "
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#focus-management-0

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

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.



Resources:


Mapping in IAccessible2 and MSAA:

"MSAA is ... able to communicate the necessary caret tracking 
information to Input Panel without the caret showing"
http://msdn.microsoft.com/en-us/library/ms811573.aspx
setCaretSelectionRect maps to CreateCaret and SetCaretPos
GetCaretBlinkTime is another mapping

IAccessible2 has ROLE_SYSTEM_INDICATOR as well as ROLE_SYSTEM_CARET


Accessibility, canvas and the scripting environment:

There is an archive available of progress within the w3c:
http://www.w3.org/html/wg/wiki/AddedElementCanvas

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"
http://groups.google.com/group/openweb-group/msg/4aeac3adce2e0907


Feedback on text fields in canvas a11y:

Ian Hickson worries that caret location "might encourage ... use ... for 
text fields".
http://lists.w3.org/Archives/Public/public-html/2010Jul/0219.html

David Bolter will be "evangelizing against" (demonizing) "canvas for 
text editing",
http://www.w3.org/2011/01/17-html-a11y-minutes.html

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"
http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0042.html

Frank Olivier reports: "the IE team does not think that text editing via 
canvas is a problem that we should tackle for HTML5"
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0007.html

Richard Schwerdtfeger notes "even if Rich Text Editing is not supported, 
at this time, we will need to support a caret and focus ring"
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0009.html

Received on Monday, 24 January 2011 01:37:29 UTC