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

Chuck,

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

Rich

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
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