Re: Accessibility in Canvas: custom widgets

Apparently, Ian is going to continue to use accessibility as a vehicle to
prevent authors from writing code the way he sees fit. He tried to do this
with the ARIA section and he is trying to do it with canvas. Authors will
continue to write code the way they see fit and they are not going to
consult Ian. By restricting elements in this way he is making canvas
inaccessible.

I will fight this effort by Ian. I am more than happy to see the WhatWG
spec. to continue on its merry forking ways. It makes it very easy for me
to point to the WhatWG series of specifications as the inaccessible version
of HTML 5.

Any browser that adopts the WhatWG specifications will clearly not be
accessible.

I think the best thing that could happen for the W3C is for WhatWG to
continue to fork like this.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From: Charles Pritchard <chuck@jumis.com>
To: public-canvas-api@w3.org
Date: 06/13/2011 02:19 AM
Subject: Accessibility in Canvas: custom widgets
Sent by: public-canvas-api-request@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
usable"
http://lists.w3.org/Archives/Public/public-html-diffs/2011May/0173.html


Annotated patch:
http://html5.org/tools/web-apps-tracker?from=6144&to=6145


Paul Cotton expressing Chair's request to revert patch:
http://lists.w3.org/Archives/Public/public-html/2011Jun/0083.html


Tab Atkin's bug report:
"Canvas should not pretend that it can be used to replace some input
elements"
http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jun/0260.html


W3C issue tracker on [Bug 12906]:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
http://www.w3.org/TR/UAAG20/


WCAG 2.0
http://www.w3.org/TR/WCAG20/

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
http://www.w3.org/TR/html4/interact/forms.html

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

HTML5
http://www.w3.org/TR/html5/the-input-element.html

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

Notes:

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"]