- From: Charles Pritchard <chuck@jumis.com>
- Date: Sun, 23 Jan 2011 17:36:58 -0800
- 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 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