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

Status of Canvas A11y Bug Reports

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 01 Aug 2011 12:54:09 -0700
Message-ID: <4E370461.7080609@jumis.com>
To: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
Status of Canvas A11y Bug Reports

The following report lists the bugs identified and opened through
public-canvas-api and Canvas A11y teleconferences placed since October 2010.

The bugs are based on heavy testing of keyboard and pointer events,
and visual/spatial cues as they relate to HTML canvas widgets.

They target existing accessibility APIs. My notes reference IAccessible.

Please note that in the past, the term "canvas shadow dom" was used
to describe the DOM subtree belonging to a canvas element.

The term "focus ring" has been used to describe the visual behavior
that accompanies keyboard focus on interactive elements; typically,
the drawing of a highlight border or dotted line.

This is a fairly conclusive list of the issues brought up, their status,
and possible routes to resolution.

Currently, Canvas A11y testing should be performed in IE9 F12 Developer 
as Microsoft has implemented the Canvas DOM subtree behavior necessary for
keyboard accessibility, focus management and resolution management.

I hope to see similar support in WebKit and Mozilla in the near future.

Bug 11238 - Enable canvas to support accessible rich text editing

Resolution notes:

Duplicate of Issue #131.
ISSUE-131: Should we add a caret location API to canvas, or is the focus 
API sufficient?
Issue #131 was resolved by scrollPathIntoView in the WHATWG spec, 
setCaretSelectionRect in the W3C spec.

Functionality for "grammatical and spelling errors" is being tested in 
WebKit on HTMLElement.
ARIA provides the aria-invalid attribute to be used in the Canvas DOM 

Bug 11239 - Canvas support accessible caret tracking independent of 
Focus Ring tracking (edit)
Status: NEW
Priority: P3 Blocker


WHATWG and W3C specs forked on issue #131, leaving this bug report open.
The focus ring steps on the WHATWG specification are out of order.
See notes for Bug 11241. The caret tracking and focus ring changes were 
put forward
in the same CP.

There is still some confusion about system vs UA focus rings.

Once we can clear up some of these confusions, I believe we can merge 
the WHATWG and W3C specs
and close this issue.

The WHATWG scrollPathIntoView method addresses 11239

Bug 11240 - Canvas support accessible selection position tracking 
independent of Focus Ring tracking
Resolution Notes:

This bug acts as additional info for:
And duplicates Issue #131

This bug is addressed by the WHATWG scrollPathIntoView method and DOM 
The WHATWG and W3C canvas 2d specs are currently forked, leaving this 
bug unresolved.

Bug 11241 - Canvas support accessible Focus Ring tracking independent of 
caret or selection tracking


Our intent in working group spec was to send line drawing information to 
the UA,
at which point the UA may present a stylized focus ring based on that 
or it may present a ring based on preferences set by the OS. An AT will also
be notified of the focus event, and may independently handle the event. 
These do
not alter the canvas surface.

Should an author want to draw a custom focus ring, they may set the line
drawing settings to transparent, and subsequently draw a custom focus
ring onto the Canvas surface, and further manage the redraw steps.

The WHATWG spec has the steps out of order, leaving the AT notification 
for the last step. This is incorrect.
The WHATWG spec includes multiple calls to drawFocusRing during a single 

Authors already have information as to whether or not a child element is 
in focus,
via onfocus handlers on child elements.

Several developers have become confused with the term "focus ring".
CSS uses the term "outline".

Bug 11242 - Canvas must define what HTML elements may be used in the DOM 


There was some discussion about restricting certain HTML elements from being
used in the DOM subtree. This issue has been resolved, the subtree will 
not be restricted.

Bug 11328 - Canvas authors needs to be able to assess pixel resolution 
to rescale canvas elements
Status: NEW
Priority: P2 normal


Microsoft's window.screen extensions expose pixel resolution to the 
scripting environment.
WebKit developers have agreed to follow with the same naming and behavior.
Mozilla requires a series of CSS queries to identify pixel resolution.

Once WebKit has implemented the window.screen extensions, it is very likely
that they will be added to the standard behavior.

Authors targeting SVG paint servers and/or CSS transforms will have to 
take those additional
matrices into account.

Resolution is pending an implementation from WebKit or Mozilla.

Bug 11329 - HTML 5 supporting browsers must generate resize event during 
a zoom. (edit)
Status: NEW
Priority: P2 major


This is the current behavior in all browsers, but has not been added to 
It duplicates Issue #109.

Bug 11342 - TextMetrics should include distance from textBaseline to 
each of the baselines in the text


This is simple behavior, with code points provided for both WebKit and 
It appears the editor and chars did not understand the proposal. This 
issue is pending a followup
change proposal, as it was introduced with the CP that handled caret 
tracking, bug #11239.

This proposal adds a y-offset value named baseline to the object 
returned by measureText,
allowing authors to accurately position the caret based on the current 
value of the textBaseline property.

Bug 13176 - The bounds of canvas fallback content, as rendered on the 
canvas, are not provided by the user agent to an assistive technology
Status: NEW
Priority: P1 blocker


Several ATs require basic hit testing information for interactive 
regions. accLocation is the most common
method, from IAccessible, which requires a bounding box. There are 
currently several proposals to bind a subtree element to
the current path, in the accessibility tree. As a means of encouraging 
developers to use and test the methods,
it's been recommended that the bound paths are also used by the UA to 
route pointer events directly to the subtree,
implementing the code path necessary for accHitTest to function.

Bug 13181 - Canvas does not allow mouse events to be directed to 
keyboard accessible objects in fallback content
Status: NEW
Priority: P1 major


Canvas developers currently manage hit testing from the canvas element. 
With the subtree implemented,
mouse events could go directly to subtree elements. Keyboard events 
currently go directly to subtree elements.
This is related to bug #13176

Bug 13391 - Add a ScrollElementIntoView function
Status: NEW
Priority: P2 normal


The WHATWG spec currently has scrollPathIntoView to both set caret position
and scroll a portion of a canvas into the view port, similar to the 
scrollIntoView from CSSOM.

Subtree elements should have data about their visible dimensions for 
ATs, per bug #13176

Some ATs will send scroll requests: running scrollIntoView on elements 
in the canvas subtree
does not currently work. The resolution of this issue relies on #13176.


Received on Monday, 1 August 2011 19:55:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:32 UTC