Canvas Accessibility for Pointer Events and Spatial Awareness

Canvas Accessibility for Pointer Events and Spatial Awareness

Since 2009 [1], various experts have put forward proposals within W3C 
working groups on how to enable authors to author accessible canvas 
applications. Accessibility, in this case, is defined by the 
programmatic access that an author and user agent provide to assistive 
technologies running on a clients computer, as well as the ability an 
author has to generate legible output within the user agent, absent 
external assistive technology.

The facilitation of programmatic access is called for in several 
accessibility guidelines. [2][3]

"Several Success Criteria require that content (or certain aspects of 
content) can be 'programmatically determined.' This means that the 
content is authored in such a way that user agents, including assistive 
technologies, can access the information." [4]

User agent (UA) vendors have an obligation [see: Excerpts from UAAG] to 
enable content authors to expose such attributes as are necessary to 
meet WCAG success criteria. In the case of HTML5 Canvas, this has been a 
slow process, and as of June 2011, only one vendor [5] has released an 
implementation of Canvas with methods to enable focus management as 
defined by W3C HTML Canvas 2d Context [6]. Another major vendor has 
attempted similar implementation of the focus specification, but has not 
completed the task. [7] Following the successful introduction of focus 
management, caret location tracking was approved in a contentious 
decision. [8] The HTML5 editor subsequently forked the WHATWG canvas 
specification [9], introducing scrollPathIntoView, as a means to further 
drive accessibility and meet success criteria. The HTML5 editor 
introduced two focus ring methods in an attempt to address some of the 
issues brought forward during the caret location tracking decision. 
Though there are some outstanding issues [10][11] relating to text 
legibility, the overall state of Canvas accessibility in relation to 
keyboard access has been greatly improved.

Currently, the Canvas accessibility working group is soliciting feedback 
and proposals relating to pointer devices and spatially aware assistive 
technologies. This topic [12] was covered in 2009 with several 
suggestions still under consideration. [13][14] There is a building 
consensus that path data as defined by the SVG standard is a useful 
vessel for exposing path information for programmatic access, though the
semantics of doing so have not solidified. [15][16] Proposals put 
forward by Richard Schwerdtfeger and Charles Pritchard [14][17][18] have 
attempted to update the Canvas specification to add a method which 
authors could use to expose the current path and bounding box to the 
system accessibility API. These proposals have been identified as 
components which belong to "retained mode graphics" specifications, with 
two vendors [19][20] stating that such methods belong in the SVG 
specification, not within Canvas. Tab Atkins has most succinctly 
expressed objections to the proposals: "You are attempting to recreate a 
retained-mode API in an immediate-mode API.  Why is 'use SVG' not 
sufficient for this?" [21]

In the days following comments by Microsoft, Apple and Google developers 
stating accessible rendering should be done through SVG, there has been 
some movement back to investigating solutions for canvas accessibility. 
Tab Atkins has solicited "use cases" that meet the style and substance 
of WHATWG documentation. [22] By building consensus on such use cases, 
it may be possible to regain a consensus amongst vendors that canvas 
accessibility is an issue which must be solved within the realm of the 
Canvas specification. Defining such use cases has been difficult, as 
many vendors and developers are quick to declare that using canvas for 
user interface components is not an appropriate use of the tag. Other 
developers and vendors have stated that "correctness" is not relevant: 
Canvas must be usable in an accessible manner for it to be included in 
HTML5. This later sentiment seems to be correct, per W3C policies and 
guidelines.


Tab Atkins put forward the following as an exemplary use case [22], 
based on my input [Charles Pritchard]:

1. A user should be able to indicate a portion of a complex image and 
get a caption associated with that portion (possibly not visible in the 
image).

Additional use cases have been put forward, but have so far, been 
contentious.
I'd like to put forward the following use cases.

2. A user of an assistive technology should be able to navigate through 
particular element types, such as buttons or table cells, with visually 
enhancements. These enhancements may include zooming in to particular 
elements, drawing an indicator around or atop discovered elements, or 
otherwise redraw the discovered element in a separate portion of the screen.

3. An author supporting legacy software or supporting remote access 
should be able to maintain and/or improve accessibility of the software 
for users. Remote access and legacy software clients have been 
implemented, as have interpreters for common virtual machines, and they 
use Canvas for graphic output as SVG is either non-performant or does 
not fit the immediate mode semantics of the underlying client software.

4. A user should be able to indicate with a pointer device, without 
setting focus, that they are interested in the role of an interactive 
element rendered within a canvas element. The Canvas specification puts 
forward a simple checkbox example. A user, employing only a  pointer 
device and an assistive technology should be able to move their pointer 
device over the checkbox, and signal to the assistive technology that 
they would like information about the DOM element that their pointer 
device is currently hovering. In the case of touch  devices, touch is 
used instead of hovering. The AT would be able to determine, 
programatically, that the user is hovering over an element within the 
canvas subtree, and would then be able to report the rich semantic 
details contained.

These use cases are based on the reality and the specifications that 
exist on the web today. Though SVG2 and XBL2 may provide further 
benefits and better methods to manage accessibility, they are still in 
early stages of production. It is quite likely that the manner in which 
Canvas applications are made accessible will be re-used within SVG2 and 
XBL2, as they also require a high degree of semantic markup. Improving 
Canvas accessibility is an important step in the development of those 
two technologies.


Citations

[1] ISSUE-74: How accessibility works for <canvas> is unclear.
http://www.w3.org/html/wg/tracker/issues/74

[2] User Agent Accessibility Guidelines (UAAG) 2.0
http://www.w3.org/TR/UAAG20/

[3] Web Content Accessibility Guidelines (WCAG) 2.0
http://www.w3.org/TR/WCAG20/

[4] Understanding WCAG 2.0 - Understanding Conformance
http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-programmatically-determined-head

[5] RE: Canvas shadow DOM question for interactive HTML5 elements
http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0002.html

[6] HTML Canvas 2D Context - 10 Focus management
http://dev.w3.org/html5/2dcontext/#focus-management

[7] Bug 50126 - Fallback content in canvas element not focusable
https://bugs.webkit.org/show_bug.cgi?id=50126

[8] 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

[9] HTML Living Standard
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html

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

[11] Bug 11328 - Canvas authors needs to be able to assess pixel 
resolution to rescale canvas elements
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328

[12] Improve image maps and use them to make canvas accessible
http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom

[13] Re: hit testing and retained graphics - Edward O'Connor
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0024.html

[14] Re: hit testing and retained graphics - Charles Pritchard
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0047.html

[15] Retain Accessibility Immediately
http://schepers.cc/retain-a11y-immediately

[16] Re: hit testing and retained graphics - Charles Pritchard (on SVG 
markup)
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0041.html

[17] feedback requested: Canvas change for improved hit testing that 
also facilitates accessibility
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0090.html

[18] Canvas positioning issue - possible solution (feedback requested).
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0081.html

[19] RE: hit testing and retained graphics - Frank Olivier on behalf of 
Microsoft
"We have no plans to add retained capabilities to the immediate mode 
canvas API."
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0070.html

[20] Re: hit testing and retained graphics - Edward O'Connor relaying 
feedback from Apple
"Grafting random pieces of a retained-mode API into it is bad design."
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0080.html

[21] Re: hit testing and retained graphics - Tab Atkins Jr. a Google 
employee
http://lists.w3.org/Archives/Public/public-html/2011Jun/0339.html

[22] Re: hit testing and retained graphics
"The WHATWG wiki pages ... exemplify what is meant by compiling clear 
use-cases"
http://lists.w3.org/Archives/Public/public-html/2011Jun/0420.html


Excerpts from UAAG
http://www.w3.org/TR/UAAG20/

2.1.1 Platform Accessibility Architecture: Support an platform 
accessibility architecture relevant to the operating environment. (Level A)
2.1.6 Properties: If any of the following properties are supported by 
the accessibility platform architecture, make the properties available 
to the accessibility platform architecture: (Level A)
(a) the bounding dimensions and coordinates of rendered graphical objects
2.1.7 Timely Communication: For APIs (for non-web-based user agents) 
implemented to satisfy the requirements of this document, ensure that 
programmatic exchanges proceed at a rate such that users do not perceive 
a delay. (Level A).


PRINCIPLE 3: Perceivable - The user interface and rendered content must 
be presented to users in ways they can perceive

3.1.1 Identify Presence of Alternative Content The user has the ability 
to have indicators rendered along with rendered elements that have 
alternative content (e.g. visual icons rendered in proximity of content 
which has short text alternatives, long descriptions, or captions). In 
cases where the alternative content has different dimensions than the 
original content, the user has the option to specify how the 
layout/reflow of the document should be handled. (Level A).
3.1.4 Rendering Alternative (Enhanced): Provide the user with the global 
option to configure a cascade of types of alternatives to render by 
default, in case a preferred type is unavailable. If the alternative 
content has a different height or width, then the user agent will reflow 
the viewport. (Level AA)

Guideline 3.10 Help user to use and orient within viewports.

3.10.2 Move Viewport to Selection and Focus: When a viewport's selection 
or content focus changes, the viewport moves as necessary to ensure that 
the new selection or content focus location is at least partially in the 
viewport. (Level A)

Guideline 3.11 Provide an effective focus mechanism.

Guideline 4.6 Provide text search. [Implementing 4.6]

4.6.1 Find:The user can perform a search within rendered content (e.g., 
not hidden with a style), including text alternatives, for any sequence 
of characters from the document character set set[sic]. (Level A)

Received on Saturday, 2 July 2011 18:25:50 UTC