W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: HTML-A11Y Task Force Recommendation: ISSUE-74 Canvas-Accessibility

From: James Graham <jgraham@opera.com>
Date: Tue, 15 Jun 2010 11:37:06 +0200
Message-ID: <4C1749C2.5010804@opera.com>
To: Janina Sajka <janina@rednote.net>, HTML WG <public-html@w3.org>, Steven Faulkner <faulkner.steve@gmail.com>, schwer@us.ibm.com, public-html-a11y@w3.org
On 06/14/2010 10:16 PM, Janina Sajka wrote:

> http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility

Some thoughts on these changes:

== drawFocusRing(element, x,y,w,h,[drawCustomRing]) ==

The algorithm for determining the rectangle fails to take account of the 
current transformation matrix. This seems bad because it means that 
under general transformations, the focus region will be the wrong size.

In general if the current path is known, it seems that it is possible 
for the UA to calculate the best-fitting size of the bounding rectangle. 
Therefore it is unclear why the author is expected to recompute this 
size explicitly.

It is unclear why the focus ring is restricted to a rectangle in the 
UA-drawn case when it is allowed to follow an arbitary path in the 
original spec.

It is unclear to me what it means to "draw the focus ring based on the 
final role computed from the native host language semantics and the 
supplied role attribute"

The step to return false when the UA draws the focus ring seems to be 
missing.

== setCaretSelectionRect(element, x, y, w, h) ==

I found the introductory text quite hard to follow here. In addition, 
there are several typos. As an author I think I would have considerable 
difficulty figuring out what I was supposed to use this method for even 
if I thought I needed it.

It is not clear why this method only works when an element is focused. 
Although the caret is tied to focus, the selection can presumably 
adjusted without focusing the selected element (e.g. a select text 
button in the application UI).

There is no canvas API that allows one to measure the height of text. 
Therefore asserting that users must do this seems unreasonable.

The algorithm for UA processing of getCaretSelectionText seems to mix in 
a bunch of author requirements. Step 2 has a list of 2 author 
requirements followed by 1 UA requirement. Step 5 talks about "your UA", 
which doesn't make sense. This algorithm should be rewritten to just 
contain UA requirements and author requirements should be elsewhere.

It is not really clear what happens when the selection is 
non-rectangular (e.g. multiline text). I assume authors are supposed to 
provide the bounding box of the selection?

It is not clear to me why the (x,y) cooordinates may either be at the 
top-left or the top right. How does the UA distinguish those cases?

== caretBlinkRate() ==

I am unconvinced this is needed. Is it a big problem if authors always 
draw carets that blink at 2Hz or less? [1] documents the range of 
frequencies that cause problems as 3Hz-60Hz, and the text of this 
document says that the common default is 2Hz. Why not just state that 
carets should not blink more rapidly than 2Hz? It also seems like an 
typical canvas application may have many more flashing elements than the 
caret. Why is it considered special?

The requirement that "when drawing a blinking caret [the rate] must 
reflect the blink rate returned by this method." seems like at most a 
SHOULD requirement. e.g. if I want an unblinking caret because I prefer 
it that should not be forbidden.

The requirement that "the author must determine the blink rate" seems 
unreasonable unless you just mean "the author is free to specify a blink 
rate of their choice" in which case it should be rephrased.

== General comments ==

These changes appear to be designed specifically for bespin-like 
applications. That seems like a tiny minority of all canvas 
applications. Have we checked directly with the bespin developers if 
this API addresses their needs? If not I believe that is essential.

The API doesn't really have any visible effects in the non-accessibility 
cases. That suggests that it will be widely ignored or misused. Has any 
thought been given to ways of avoiding this?

More examples are needed. The existing example should be relocated to 
its original location and fixed so it actually uses the new API.

[1] http://www.epilepsy.org.uk/info/photosensitive/intro
Received on Tuesday, 15 June 2010 09:38:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:09 GMT