Fwd: Canvas Accessibility for Pointer Events and Spatial Awareness

FYI

---------- Forwarded message ----------
From: Charles Pritchard <chuck@jumis.com>
Date: 2 July 2011 19:24
Subject: Canvas Accessibility for Pointer Events and Spatial Awareness
To: public-canvas-api@w3.org
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <
eoconnor@apple.com>, "franko@microsoft.com" <franko@microsoft.com>, Richard
Schwerdtfeger <schwer@us.ibm.com>, "Mike@w3.org" <Mike@w3.org>,
jbrewer@w3.org


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<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<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<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<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<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<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<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<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<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<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<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<http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0047.html>

[15] Retain Accessibility Immediately
http://schepers.cc/retain-**a11y-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<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<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<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<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<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<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<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)





-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html