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

Rich Schwerdtfeger
CTO Accessibility Software Group

James Graham <jgraham@opera.com> wrote on 07/15/2010 04:40:47 AM:

> From: James Graham <jgraham@opera.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Steven Faulkner <faulkner.steve@gmail.com>, Janina Sajka
> <janina@rednote.net>, HTML WG <public-html@w3.org>,
public-html-a11y@w3.org
> Date: 07/15/2010 04:48 AM
> Subject: 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.)
>

That's fair.

> >  > == 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.
>
ok. I will correct.

> > 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.
>
With the absence of a drawing path with and height are necessary to
complete the drawing of a focused object.
If the drawing path is required it may not be necessary to have a width and
height at all.

> >  > 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.
>
Agreed.

> >  > 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.
>
will correct.

> >  > == 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?
>
Operating systems may trigger focus tracking off a rectangle vs. a single
point.

> 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.

Alright. I understand why as Hixie thinks it provided added value where the
author would get
accessibility for free.

He needs to understand a caveat and it is one that created some additional
challenges for
us in righting this. Mac accessibility mixes caret and selection tracking.
For example,
when I select text with a mouse on the Mac I don't move the caret. In this
case a magnifier is actually
tracking the end of the selection. It is not until you then use the
keyboard or click elsewhere that
you actually force a caret change event and draw a caret.

On Windows a caret is also move with the end of the selection. So, if this
is the case then Hixie and
Maciej should consider a selection API to draw the selection.

So, if there is a caret and selection API I will provide text that is
included in the spec regarding
how the API implementation should drive magnification. We would actually
prefer a caret drawing and selection
drawing features but we felt that overstepped the bounds of what the
accessibility effort should be specifying for canvas.

In the mean time I will update our proposal to reflect the feedback and
post it for review.

Rich