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

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)

<Hixie> gotta love
http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility
 # <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-432> [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()"
 # <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-434> [08:46] <Hixie>
my god this proposal is messed up
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-435> [08:47] <Hixie> it
has authoring conformance criteria literally in the middle of a UA algorithm

# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-436> [08:47] <Hixie> it
uses the wrong coordinate system
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-437> [08:47] <Hixie>
it's self-contradictory in fact about the coordinate system it uses
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-438> [08:48] <Hixie> it
has an entirely useless set of arguments for the focus ring

<Hixie> seriously, read this:
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-448> [08:50] <Hixie>
http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/att-0054/2dcontext10-June-7.html#dom-context-2d-setCaretSelectionRect
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-449> [08:51] <Hixie>
the definition of setCaretSelectionRect
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-450> [08:51] <Hixie>
read that algorithm
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-451> [08:51] <Hixie> it
has authoring criteria, it has asynchronous requirements, and then it ends
with "return true"
 # <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-453> [08:52] <Hixie>
and that's ignoring the main problem of course, which is that the entire
method is completely useless
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-454> [08:52] <Hixie> it
does nothing if you don't have an AT, so nobody will ever use it
# <http://krijnhoetmer.nl/irc-logs/whatwg/20100715#l-455> [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?



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