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

Use Case: setCaretSelectionRect - Canvas Accessibility Working Group

From: Charles Pritchard <chuck@jumis.com>
Date: Sat, 29 Jan 2011 22:55:25 -0800
Message-ID: <4D450B5D.4060300@jumis.com>
To: public-canvas-api@w3.org
CC: Richard Schwerdtfeger <schwer@us.ibm.com>, franko@microsoft.com, david.bolter@gmail.com, public-html-a11y@w3.org, swarren@aisquared.com, tlalor@aisquared.com, dmazzoni@google.com
Note: these example sites are not "canvas"-based. Raster and canvas 
examples have been documented in other threads.



Attached is a screenshot of "Google Instant" keyboard navigation;
my caret is on the bottom-most link.

When tab is used, a focus ring is drawn on various elements.

drawFocusRing is not typically used for "caret" ui controls.

setCaretSelectionRect is useful for indicating sub-regions.



Attached is a screenshot of "Bing Images", with an image selected via mouse.

Though bing image search does not seem to have workable keyboard 
navigation, it's still a reasonable use case.

In this area, drawFocusRing might apply to the outermost rectangle,
and caret selection would define a 'sub-focus' on the secondary content,
below the selected image.

The existing whatwg model of drawFocusRing requires an x,y parameter:
That parameter was dropped in our new, proposal.

setCaretSelectionRect adds on width and height data, as a better means
of "hinting" to the AT software.

The word caret is used, because it corresponds to 'caret' APIs on many 
platforms, including Java and Windows. It's most often used with text 
content, with "height" and "height" parameter hinting at the font-size.



This screen shot recreates what I see when using an AT software package
with caret tracking.

Two arrows point to the area in which the caret currently has focus.

This information can be a bit difficult to pull out of an input element,
as scrollLeft and scrollWidth have mixed support with vendors (stated in 
aria-practices document).


'Caret' tracking is not well defined for composite elements:


"3.2. Providing Keyboard Focus" does not currently mention caret.
"10. Design Patterns" mentions caret only once, in "Combo Box (widget)" 
Keyboard Interaction.

Engaging the "Authoring Practices" document mentioned, may be a 
reasonable step in bringing Canvas a11y into line with WAI-ARIA.

Some good points from the document:

The "Rich Text Editor (widget)" ... "behavior is not defined by the rich 
internet application".... "Uses the WAI-ARIA role textbox"

The "Combo Box (widget)" responds to keyboard events, the "Left Arrow or 
Right Arrow move the caret", "Keyboard focus within the widget must be 
managed by the widget"

Received on Sunday, 30 January 2011 06:55:55 UTC

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