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

Rich Schwerdtfeger
CTO Accessibility Software Group

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

James,

Thank you for your feedback. It is much appreciated. Unfortunately, the
task force has already signed off on the proposal. We will need to address
these issues points in the HTML working group - which we both are members
of.

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.

That said, let me respond to your comments.

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

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

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

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

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

> There is no canvas API that allows one to measure the height of text.
> Therefore asserting that users must do this seems unreasonable.
>
Are you telling me the author does not know how large the text is given the
size of the canvas? Why do
you need an API to get the text height. The author does have a knowledge of
text height. They also have
a knowledge of the dimensions of the canvas which is specified in pixels. I
don't think
this is unreasonable at all.

> 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?
>
This is about the current selection text character and not the entire
selection. The magnifier
needs to show the user the point at which they are operating. The reason we
expanded this to from
just the caret selection to selection is that Apple does not have a notion
of a caret position during selection vs.
Windows which has a caret position. If you expand the zoom to the entire
selection area it is quite possible
that a low vision user will not be able to operate the selection. That is
why it is called a selection
position and not a selection area.

Imagine a user needing 10X magnification and then trying to view the entire
selection area. That won't work.

> 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?
>
That is determined by the author and not the user agent. We are asking that
the author
pass the position rectangle to the user agent and we are stating that it is
top, left or top, right
based on the last selected character.

This is very straight forward.

> == 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?
>

Some operating systems allow the user to set the blink rate. It should be
honored.

> 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.
>
It is not. The wording says "when drawing a blinking caret." Is the I here
you or the author?

We could adapt this to provide for an unblinking caret. ... I could live
with a SHOULD but
we would need to discuss this with other members.

> 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.
>
It was designed by people who designed and built screen readers and screen
magnifiers and have operated
within the graphic subsystem on multiple operating systems. We did try to
reach the Bespin
team through the Mozilla accessibility team and were unsuccessful. That
said, <canvas> is far
from novel. This is basically Windows 3.0 drawing calls done in a web page.
We were providing magnification
on these systems as far back as 1992.

We agree that Bespin is a minority case today. That does not mean that we
should remove access to it. Bespin
can be used and is being embedded in web applications today. As usual
accessibility was addressed late in the game
leaving users without access. Fortunately, the impact is minimal at this
time.

> 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?
>
Most accessibility work, including ARIA, is designed to not be intrusive to
the
visual experience. ARIA does not intrude on the visual experience and has
near
ubiquitous adoption. So, I do not agree with your assertion. What we are
trying to do
with this change is to allow a magnifier to magnify at the exact point the
user is operating - whether
it is the focus position or the caret/selection position they are on during
selection or caret typing.

Accessibility strategies like skip links to main content have ruined the
user experience for people trying to create rich desktop experiences on web
pages.

> 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