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

Response below.

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Steven Faulkner <faulkner.steve@gmail.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	HTML Accessibility Task Force <public-html-a11y@w3.org>, Janina
            Sajka <janina@rednote.net>
Date:	07/15/2010 05:08 AM
Subject:	Re: HTML-A11Y Task Force Recommendation: ISSUE-74
            Canvas-Accessibility
Sent by:	public-html-a11y-request@w3.org



Hi Rich,

james graham wrote:
> I had a short discussion on IRC with Hixie and Maciej about this API

here is some feedback on the current chnage proposal from Ian: via IRC (
http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-430)

Yes, we had a similar discussion about Ian's draft that waved its hands
about what an AT might do with a focus ring. What was there was a mess.

<Hixie> gotta love
http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility
# [08:44] <Hixie> "Currently the spec does not include requirements for
implementers on how to provide accessible focus rectangles [...] The
details of the proposal are [...] A change to drawFocusRing()"
# [08:46] <Hixie> my god this proposal is messed up
# [08:47] <Hixie> it has authoring conformance criteria literally in the
middle of a UA algorithm
# [08:47] <Hixie> it uses the wrong coordinate system
# [08:47] <Hixie> it's self-contradictory in fact about the coordinate
system it uses
# [08:48] <Hixie> it has an entirely useless set of arguments for the focus
ring

That is a good point about the location of the author's conformance
criteria. James mentioned that he preferred that we use the drawing path
for the rectangle and I agreed. I would have changed it but I was waiting
for Charles proposal. If you use the drawing path some of the arguments are
unnecessary.

<Hixie> seriously, read this:
# [08:50] <Hixie>
http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/att-0054/2dcontext10-June-7.html#dom-context-2d-setCaretSelectionRect

# [08:51] <Hixie> the definition of setCaretSelectionRect
# [08:51] <Hixie> read that algorithm
# [08:51] <Hixie> it has authoring criteria, it has asynchronous
requirements, and then it ends with "return true"
# [08:52] <Hixie> and that's ignoring the main problem of course, which is
that the entire method is completely useless
# [08:52] <Hixie> it does nothing if you don't have an AT, so nobody will
ever use it
# [08:52] <Hixie> plus it doesn't even do anything useful if you DO have an
AT, since who on earth has a selection area that is just a rectangle with
no associated selected text?

 How the heck does Hixie know what an AT does. The AT is looking for the
coordinates of the point of regard that the user is operating off of. We
could have left this as a caret but Mac platforms cannot track the users
focus during a selection. What we are looking for is where the current
point of the last selection position is. I also explained this to James
Graham and apparently he did not read my response. This was one of the most
frustrating things with this API - Apple's caret does not track the current
selection position. Apple asked that we also track the last selected
position ( not the entire selected text). A magnifier needs to be able to
track where the user is operating on the canvas during a selection or caret
track. I will try to clarify this. The challenge is that the HTML spec.
cannot mention differences in operating systems in their APIs.

I understand his point about the authoring criteria being  in the process.
I can move that out of of

And why the heck is this being communicated in WhatWG and not  in the HTML
working group. Are we supposed to go out with a rub the great crystal ball
in our offices and guess?

I will send out a revision that addresses MOST of these issues.

regards
Stevef


On 15 July 2010 10:40, James Graham <jgraham@opera.com> wrote:
  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.



--
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html