- From: James Graham <jgraham@opera.com>
- Date: Tue, 15 Jun 2010 11:37:06 +0200
- 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 UTC