Status of Canvas A11y Bug Reports

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 
Tools,
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.



----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11238
Bug 11238 - Enable canvas to support accessible rich text editing
Status: RESOLVED INVALID

Resolution notes:

Duplicate of Issue #131.
ISSUE-131: Should we add a caret location API to canvas, or is the focus 
API sufficient?
http://www.w3.org/html/wg/tracker/issues/131
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.
https://lists.webkit.org/pipermail/webkit-dev/2011-June/017242.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0545.html
ARIA provides the aria-invalid attribute to be used in the Canvas DOM 
subtree.


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239
Bug 11239 - Canvas support accessible caret tracking independent of 
Focus Ring tracking (edit)
Status: NEW
Priority: P3 Blocker

Notes:

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


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11240
Bug 11240 - Canvas support accessible selection position tracking 
independent of Focus Ring tracking
Status: RESOLVED WONTFIX
Resolution Notes:

This bug acts as additional info for:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10964
And duplicates Issue #131
http://www.w3.org/html/wg/tracker/issues/131

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


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11241
Bug 11241 - Canvas support accessible Focus Ring tracking independent of 
caret or selection tracking
Status: RESOLVED WORKSFORME

Notes:

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 
information,
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 
draw.

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


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11242
Bug 11242 - Canvas must define what HTML elements may be used in the DOM 
Subtree
Status: RESOLVED WORKSFORME

Notes:

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.


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328
Bug 11328 - Canvas authors needs to be able to assess pixel resolution 
to rescale canvas elements
Status: NEW
Priority: P2 normal

Notes:

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.


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11329
Bug 11329 - HTML 5 supporting browsers must generate resize event during 
a zoom. (edit)
Status: NEW
Priority: P2 major

Notes:

This is the current behavior in all browsers, but has not been added to 
specs.
It duplicates Issue #109.
http://www.w3.org/Style/CSS/Tracker/issues/109


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11342
Bug 11342 - TextMetrics should include distance from textBaseline to 
each of the baselines in the text
Status: RESOLVED LATER

Notes:

This is simple behavior, with code points provided for both WebKit and 
Mozilla.
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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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.


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176
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

Notes:

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.


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13181
Bug 13181 - Canvas does not allow mouse events to be directed to 
keyboard accessible objects in fallback content
Status: NEW
Priority: P1 major

Notes:

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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176


----------------------------
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13391
Bug 13391 - Add a ScrollElementIntoView function
Status: NEW
Priority: P2 normal

Notes:

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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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.

----------------------------
</end>

-Charles

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