Canvas Change Proposal Action 133

ACTION 133 on Rich Schwerdtfeger for ISSUE 74 morphed into HTML Action 165, hence content for Canvas Change Proposal Action 133 has been moved to Canvas Change Proposal Action 165.

The following is obsolete as ACTION 133 on Rich Schwerdtfeger has been closed. Visit Canvas Change Proposal Action 165 for the latest.

Summary

Describe the change in approximately one to five paragraphs of plain language.

Rationale

Describe the reason for the change. What problems does the proposal address, and how does the proposal makes things better?

Details

1. Modify the canvas element to support aria-activedescendant where the id refers to a valid id in a shadow DOM.
2. The canvas element shall support zero or more child access elements representative of alternative views. The access element shall have a mode attribute. Whose values are based on a subset of the IMS Global Consortium Access for All Meta Data V3 default. The default mode would be representative of the shadow DOM. In many instances a more usable solution may require an alternative.
3. The mode content attribute values for access would be:
• default - Representing the shadow DOM for the complex visual rendering of canvas
• textual - Here we could place a long description or an alternative accessible UI renderable using HTML 5 standard markup, including ARIA.
• auditory - An audio alternative. Some users may prefer this.
• visual - This is really an alternative for audio but it would address things like sign language
  Note: access for all also supports "tactile" and "olfactory". Recommend ignoring those for now. These could added in future releases of HTML.
4. The access element would include a type attribute for which we should take a subset of the list (from AccessForAll): audioDescription, caption, e-book, signLanguage, highContrast, transcript, alternativeText, longDescription, haptic}
   The e-book may be rendered with a plug-in. We can choose a subset of these if necessary. At this point this is for discussion purposes.
5. View Selection should be based on a user preference in the browser based on the mode and type preference supported in HTML 5. If nothing is set, the shadow DOM is used for the accessibility mapping when provided. The user agent should select the first view that fits the user's request. Platform accessibility API may also be used to configure the view selection. Note: is no alternative view is provided to meet the preferences the view reverts back to the canvas + shadow DOM view. The shadow DOM is also optional.
6. The canvas tag shall include a script method to set the bounding rectangle for a given valid id in the shadow DOM. This would allow the browser to provide the bounding rectangle for the id in the shadow DOM when it receives focus. The rectangle should be relative to the location of the canvas element and would be converted to screen coordinates in the accessibility API and would allow the canvas to move without changing the location of the shadow DOM element. This will allow screen magnifiers to determine the visible focus. (Ideally it would be nice to also do this via XPath statements vs. id)
7. All allowable HTML elements in the shadow DOM shall support the tabindex content attribute and ARIA attributes.
8. The shadow DOM should include all renderable HTML elements save standard input controls. The reasoning being is these controls are user agent managed in terms of the keyboard and would likely conflict with canvas keyboard management.

The format would be along the following lines:

<canvas aria-activedescendant="foo">
  <access mode="default">  /*Since canvas is visual this is the default mode*/
     <div role="toolbar">
        <div role="tab" tabindex="-1" id="foo">
        </div>
     </div>
  </access>
  <access mode="textual"> /*Here we could place a long description or an alternative aria-enabled widget*/
  </access>
  <access mode="auditory">
  </access>
  <access mode="tactile"> /*This is in access for all and we could lose it for now for obvious reasons*/
  </access>
  <access mode="olfactory"> /*This is in access for all and we could lose it for now for obvious reasons*/
  </access>
  <access mode="visual" type="signlanguage">
  </access>
</canvas>

Impact

Positive Effects

• List advantages

Negative Effects

• List disadvantages

Conformance Classes Changes

Describe what conformance classes will have to change.

Risks

Describe any risks.

References

• canvas Element Accessibility Issues - EWS Wiki