Canvas Accessibility Features

The Canvas A11Y sub-group would like to discuss a few options for the canvas accessibility features with the A11Y Task Force in this Thursday's conference call. Can we include this topic on this week's conference call agenda?

Recently, Firefox and Chrome engineers, the only implementers of the drawFocusIfNeeded API, have raised issues with the drawFocusIfNeeded API as currently specified in the Level 1 CR spec after our recent bug fixes [1]. Specifically, they feel that the Hit Regions method should inform the accessibility tools of the bounding regions of the fallback elements, not drawFocusIfNeeded. They would still like to include drawFocusIfNeeded to allow drawing of the focus. Since Hit Regions as currently specified has dependencies on other pieces not yet implemented, to balance the HTML WG's goal of moving Canvas 2D Context Level 1 spec forward and the task force's goal of implementing accessibility features in Canvas, we need to reevaluate what we plan to deliver in the Level 1 specification.

Specifically, we have the following options:


1)      Ship Level 1 spec without any new accessibility features, move all accessibility features to the Level 2 spec, and continue to work on implementations there.

2)      Ship Level 1 spec without any new accessibility features, implement in Level 1.1 a minimum version of drawFocusIfNeeded and Hit Regions, and compatibly implement additional details in Level 2.

3)      Ship Level 1 spec with drawFocusIfNeeded as currently specified (it informs A11Y of the region), and implement Hit Regions in Level 2 but allow its region mapping to take precedence.

4)      Ship Level 1 spec with a minimum version of drawFocusIfNeeded and Hit Regions, and implement additional details in Level 2

With Option 1 we can continue our current efforts in the Level 2 specification, push for implementations, and capture the stable definitions of these features in a heartbeat Level 2 spec. This option doesn't delay the Level 1 specification, while still helping us get to implementations and stable standards.

Option 2 allows us to instead move the work to a Level 1.1 spec, which we can quickly move through the standardization process to Recommendation once we have two full implementations. This option won't delay Level 1 and still allows us to move the accessibility standardization all the way to Recommendation, instead of just a heartbeat.

Option 3 can work but it will be confusing to web developers as there will be two ways to do the same thing. I would recommend against this option.

Option 4 would mean that in addition to drawFocusIfNeeded, we would also bring Hit Regions to the Level 1 spec. Since Hit Regions has many dependencies today, we would need to provide a minimal version of Hit Regions in Level 1 spec, that will still allow the Level 2 full definition to be compatible. Since we will need to simplify Hit Regions and come up with two full implementations of Hit Regions and drawFocusIfNeeded, this option delays Level 1 spec the most. The minimal version of the Hit Region dictionary could look like so:

dictionary HitRegionOptions {
  Element? control = null;
 DOMString id = "";

// Only use current path, Level 2 would add the path
//Path? path = null;

// Use "nonzero" fill rule by default, Level 2 would add fillRule customizability
// CanvasFillRule fillRule = "nonzero";

// Don't add any of these attributes but include them in Level 2
//  DOMString? parentID = null;
//  DOMString cursor = "inherit";

// Potentially delete these from Level 2
//  DOMString? label = null;
//  DOMString? role = null;
};

Thanks,
Jatinder

[1] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-drawfocusifneeded

Jatinder Mann | Internet Explorer Program Manager | 425.722.6247