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

On 06/16/2010 03:06 PM, Richard Schwerdtfeger wrote:

Sorry for taking so long to respond to this, it got lost somewhere in my 
pile of things to do.

> James Graham <jgraham@opera.com> wrote on 06/15/2010 04:37:06 AM:
>
>  > From: James Graham <jgraham@opera.com>
>  > To: Janina Sajka <janina@rednote.net>, HTML WG <public-html@w3.org>,
>  > Steven Faulkner <faulkner.steve@gmail.com>, Richard Schwerdtfeger/
>  > Austin/IBM@IBMUS, public-html-a11y@w3.org
>  > Date: 06/15/2010 04:37 AM
>  > Subject: Re: HTML-A11Y Task Force Recommendation: ISSUE-74 Canvas-
>  > Accessibility
>  >
>  > On 06/14/2010 10:16 PM, Janina Sajka wrote:
>  >
>  > > http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility
>  >
>  > Some thoughts on these changes:
>  >

> A frustrating point for working group members is that this proposal has
> been out for month and it was not until after an entire vote for
> consensus was reached that we get a comment from Opera. In the future it
> would be appreciated
> if we could receive comments earlier.

(I should note that my comments are not "from Opera" in any sense more 
than the minimum implied by the fact that I wrote them and I am employed 
by Opera. In particular, others at Opera might disagree with me.)

>  > == 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.
>  >
> To be clear, are you suggesting that the author need only pass the x, y
> coordinates which would be relative to the canvas area?
> The rectangle would then be computed by the user agent based on the
> drawing path from that point.

Yes.

> If so, I don't have an issue with this. We added the w, and h parameters
> in response to feedback from others.

I would be interested in hearing the use cases they presented. If there 
are cases that require something unusual, the parameters should be optional.

>  > 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.
>  >
> Accessibility API services currently use rectangles to represent the
> visual focus rectangle. We are not restricting what the author draws. This
> is why we are suggesting a rectangle best fit.

OK, I think the proposal implies that the UA may only draw a rectangle. 
The wording should be changed here.

>  > 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"
>  >
> This simply states that in the case where the user agent is drawing the
> focus rectangle based on operating system conventions then those conventions
> may require that a focus ring is drawn in a certain way based on the
> role. For example, the focus ring for a checkbox may be different from
> an item in a tree widget. Who knows, the platform may require that a
> checkbox be drawn like an ellipse or with a specific color scheme. This
> simply
> provides for that.

OK. It could be clearer in the change proposal.

>  > == 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).
>  >
> If the element is not focused or a descendant of what is focused the
> user is not directly operating with
> that UI element. They are operating another UI element and the magnifier
> needs to track
> the component the user is operating. It does not help the low vision
> user if they cannot
> see the component they are operating which would be the one with focus.

It was totally unclear to me that this was supposed to be entirely about 
the caret and not the selection. If the use case is "magnifier needs to 
know where to centre", why do you need the width and height arguments?

I had a short discussion on IRC with Hixie and Maciej about this API and 
it was suggested that the use cases might be better addressed with a 
drawCaret API. Like drawFocusRing it would have a use in the 
non-accessibility case, which would mean that it was much more likely to 
be used correctly by typical authors. With sufficient cleverness it 
could handle blinking, and the blink rate could be taken from the OS 
settings, thus eliminating the need for the caretBlinkRate() API. I 
think this design is sufficiently more promising than the existing 
proposals that we should  wait for it to be fully fleshed out before 
making any decisions here. I believe Hixie is prepared to spec out a 
drawCaret API but I don't know what his timetable is.

Received on Thursday, 15 July 2010 09:42:14 UTC