ChangeProposals/canvasaccessibilitynonav

From HTML WG Wiki
< ChangeProposals
Revision as of 14:11, 17 March 2010 by Charles (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Provide a method for canvas subtree to be hidden from all users

The following is a Change Proposal for Section 4.8.10 The canvas element of the HTML5 Specification.

Partial resolution for ISSUE 74 canvas-accessibility


  • Proposal Editor: Steve Faulkner (faulkner.steve@gmail.com)
  • Spec Change Editor: Richard Schwerdtfeger (schwer@us.ibm.com)

Date: March 16 2010.

Please address feedback to the Public Canvas API mailing list (public-canvas-api@w3.org) and the HTML Accessibility Task Force (public-html-a11y@w3.org).

Summary

Modify 4.8.10 The canvas element section of the HTML5 specification to specify a boolean attribute to indicate whether the browser should expose the content of a canvas elements subtree. Specify accessible authoring requirements for the content of a canvas elements subtree.

Rationale

Currently the specification does not provide a way for the author to indicate that the content of the canvas sub-tree should not be navigable when canvas rendering is supported by the user agent. When canvas is supported, the content of the canvas sub-tree is exposed in the DOM even though it is not rendered. Therefore, any focusable elements in the sub-tree are subject to HTML 5 focus management rules as would be elements outside the sub-tree. Should the author prefer that the sub-tree not be included in focus management a vehicle must be provided to indicate that to the browser. When the sub-tree is included in focus management it is also necessary to provide direction to authors and user agent manufacturers to use the sub-tree to create a directly accessible canvas implementation. The introduction of the nonav element is needed to give this level of functionality and guidance to authors and user agents.

In situations where alternative content, to that displayed on the canvas, is provided externally to the canvas sub-tree the author may wish to include content in the sub-tree that is inappropriate to be displayed to users, unless the user agent does not support canvas.

Example:

A canvas based chart along with a html table of the chart data included after the canvas:

<canvas nonav> Your browser does not support the graphical rendering of the data using the HTML5 canvas element, browser <a href="x.html">x</a> or <a href="y.html">y</a> is required.</canvas>

<table> chart data </table>

A canvas based chart along with a html table of the chart data inside the canvas element:

<canvas> <table> chart data </table> </canvas>

The use of the boolean attribute "nonav" provides an indication to the browser that canvas subtree content must not be exposed and allows for the use of the canvas subtree for content that should only be displayed when canvas is not supported by the browser.

Details

The details of the proposal are contained in the form of spec ready text that has been included in a copy of the W3C Working Draft revision 1.3833 of the section 4.8.10 The canvas element of the HTML5 specification.

The modified parts are denoted by the marker <ZZ> at the start and </ZZ> at the end.

HTML5 specification section 4.8.10 The canvas element (modified)

The main normative changes involve the addition of a boolean attribute "nonav" that when present indicates that canvas subtree content must not be exposed by the user agent and focusable elements in the subtree must not be included in the tab order. Furthermore additional author conformance requirements are included:

"The canvas element has a third boolean attribute, nonav that applies to user agents supporting canvas, to indicate if the canvas subtree elements are not focusable as defined by Focus Managment. If it is absent, standard HTML elements may be used in the canvas sub-tree, however the rendering of the subtree is controlled by script through the canvas API. The nonav is absent, the default, it indicates that the elements within the canvas sub-tree MUST be rendered transparently to ensure inclusion in the HTML focus navigation order without effecting the visible rendering of the web page. When nonav is absent, user agents that support an accessibility API MUST map the HTML elements in the subtree to the accessibility API, as they would map the same elements outside the subtree. When nonav is absent, the canvas must be synchronized with the canvas rendering. If the attribute nonav is present, it indicates that the canvas subtree MUST NOT be included in focus navigation. Authors MUST include the nonav attribute when the content within canvas is not intended to represent the focus navigation for the visible elements drawn on canvas. To support accessibility in the navigable sub-tree the author MUST:

  • MUST synchronize the accessible sub-tree elements, semantics, and structure with the canvas rendering.
  • MUST render and maintain visible focus of the canvas subtree element on the rendered canvas.
  • MUST render and maintain the keyboard caret insertion cursor of the canvas subtree element on the rendered canvas."

Impact

Positive Effects

  • Provides a simple mechanism for authors to use to ensure that content in the canvas subtree is not available to users of user agents that support canvas, when the content has been authored for the situation when canvas is not supported.
  • States clearly what authors are required to do to provide accessible content when the canvas subtree is used as a container for content providing interaction and semantics in browsers that support canvas.
  • States clearly how user agents, that support accessibility API, should process the subtree to support the accessibility API
  • Clarifies, how focus management should be supported in the canvas sub-tree
  • disambiguates the case where canvas sub-tree content is not fallback.

Negative Effects

  • Places additional requirements on implementors, the current version of the spec does not.
  • Places more stringent requirements on authors, the current version of the spec does not.
  • Adds an additional attribute.
  • Provides an opportunity for unintentional hiding of content in cases where it should be exposed.

Conformance Classes Changes

unknown

Risks

unknown