W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2011

Accessibility in Canvas: custom widgets

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 13 Jun 2011 00:17:14 -0700
Message-ID: <4DF5B97A.7040006@jumis.com>
To: public-canvas-api@w3.org
Recently, Ian Hickson introduced a change, later reverted by request 
from the Chairs, which would restrict Node types contained within the 
canvas shadow dom. Tab Atkins followed up with a bug report on the w3c 
issue tracker. It was subsequently closed by Ian Hickson, referring Tab 
Atkins to the escalation process as a means to appeal the decision.

Following these citations are some excerpts from WCAG2.0, HTML 4.0 and 
HTML5 documents, relating to input elements

Ian Hickson's patch:
"Further discourage misuse of <canvas> that cannot be made accessible or 

Annotated patch:

Paul Cotton expressing Chair's request to revert patch:

Tab Atkin's bug report:
"Canvas should not pretend that it can be used to replace some input 

W3C issue tracker on [Bug 12906]:

These citations on the input element and user interface requirements for 
Level AAA compliance
demonstrate that the proposal by Tab Atkins as well as the change by Ian 
Hickson would prevent
the use of canvas implement custom input types as defined by the WCAG 
2.0 on forward compatibility (section 4.1).

The change proposals put forward by Tab Atkins and Ian Hickson seem to 
be intended only to disable
input type="text". This is not technically feasible, as "text" is the 
default value of the input tag.

In response to their intent: WCAG 2.0 allows Images of Text at Level AAA 
compliance provided such
"images ... are only used for pure decoration or [for a] particular 
presentation ... essential to the information being conveyed".

This includes Logotypes; a logotype editor might use input type="text" 
to facilitate programmatic access.

The canvas shadow dom should allow this use of input type="text" as UAAG 
2.0 compliance demands the user agent "[f]acilitate programmatic access" 
and provide an "effective focus mechanism" in working with web and 
non-web content. The HTML5 canvas tag and html input elements are being 
examined by the public-canvas-api group in reflection of WCAG 2.0 
Principle 4 "Content must be robust enough that it can be interpreted 
reliably by a wide variety of user agents, including assistive 
technologies" to "[m]aximize compatibility with current and future user 
agents, including assistive technologies."

UUAG 2.0

WCAG 2.0
1.4.9 Images of Text (No Exception)
Logotypes … are considered essential
4.1.2 Name, Role, Value: For all user interface components … 
notification of changes to these items is available to user agents, 
including assistive technologies

HTML 4.0
17.4 The INPUT element
type … This attribute specifies the type of control to create. The 
default value for this attribute is "text".

4.10.7 The input element
The type attribute controls the data type ... It is an enumerated 
The missing value default is the Text state.


It is common practice that elements which are not implemented by the 
user agent are displayed as text fields; this practice is inherited from 
old browsers and from old HTML specs. In the following illustration, 
three levels of implementation are shown,
one representing a UA which has implemented slider, one which has not, 
and one which simply displays fallback content as would be shown in HTML 
4.0 compliance.

Slider implemented, original (HTML5 compliance):
[canvas][input type="slider"][/canvas]
Slider not implemented, input.type is now interpreted as text (Canvas 
supported, slider not implemented)
[canvas][input type="text"][/canvas]
Neither canvas nor slider are implemented, fallback content shown: 
(Canvas not supported, slider not implemented)
[input type="text"]
Received on Monday, 13 June 2011 07:17:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:30 UTC