Re: Draft Revisions to Canvas 2D Context API to drive magnification

Hi James,

Response below per today's canvas accessibility meeting  (you were cc'd). I
will be working on an updated draft of the changes for review.

Rich Schwerdtfeger
CTO Accessibility Software Group

James Craig <jcraig@apple.com> wrote on 05/24/2010 12:54:07 AM:

> James Craig <jcraig@apple.com>
> 05/24/2010 12:54 AM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> cc
>
> Eric Carlson <eric.carlson@apple.com>, HTML Accessibility Task Force
> <public-html-a11y@w3.org>, public-html-a11y-request@w3.org, Frank
> Olivier <franko@microsoft.com>, david.bolter@gmail.com, "public-
> canvas-api@w3.org" <public-canvas-api@w3.org>, surkov.alexander@gmail.com
>
> Subject
>
> Re: Draft Revisions to Canvas 2D Context API to drive magnification
>
> Richard Schwerdtfeger wrote:
>
> > It would be good to have either you or James on the canvas api call
Monday.
>
> Unfortunately, I have a conflict that will prevent me from attending.
>
> > James Craig wrote:
> >
> >> Initial feedback for the proposed methods:
> >>
> >> 1. The focus ring should be a set of coordinates or a shape
> rather than a single xy coordinate. At a minimum, it should be rect
> (x1, y1, x2, y2), but it'd be better to use a standard shape as the
> parameter, e.g. line, rectangle, ellipse, or polygon... Poly would
> allow not only non-standard shapes, but would also provide an easy
> way to implement focus rings for UI elements that appear skewed or
rotated.
> >
> > 1. The reason I chose only an x, y position is we felt the
> rectangle could be determined from the associated object. That said,
> I can see why a polygon would be more powerful.
>
> The bounds could be determined automatically if only a single point
> were provided. That said, the size and shape of the associated
> shadow DOM object may not be the same as the canvas representation
> of the UI element, so the parameter should leave the option for a
> point or a shape.
>
> > Frank, David, Alex, Are you on board with supporting a polygon?
> Essentially I would supply a collection of vertices for which would
> cover the polyline. We would then need to convert that to the
> objects bounding rectangle in the accessibility API.
>
> Any standard shape should be accepted, not just polygons. Most
> common will probably be rect() and poly()…
>
The group in attendance (per today's canvas accessibility call) determined
that most accessibility APIs only provide a focus rectangle. Although the
author can draw any shape they like it was agreed that when the the
coordinates are passed for accessibility that they provided as a best fit
rectangle. I will also make this all clear in the next draft for review.

> >> 2. Caret position should likewise have more than one coordinate
> or shape(s), especially since I assume this is intended to work for
> both selection ranges as well as unselected caret position.
> >
> > 2. Caret position - This is solely for magnifier tracking. So, ...
> >
> > - You only need to follow the last point of regard position. You
> can't have a magnifier magnify in two places. So, why do want to
> specify ranges. I think this unnecessarily complicates the problem.
>
> If the user's zoom level can display the entire selection, it
> probably should. Most common usage will still be a single caret
> position, but there should be an option for authors to specify the
> size, shape, and location of the entire selection range. Also, a
> single point does not indicate font-size/line-height on the canvas
> representation of the control. Without the additional information,
> for example, a magnifier may only display the top-half of the text
> or line-box on the canvas.
>
The group in attendance resolved that the autozooming feature could
actually break accessibility. If the user were to set a magnification level
based on their vision and then the system were to auto zoom to fit all the
text in this could result in a lower magnification level making the
experience less accessible. At this time the group agreed to pass a
rectangle as the parameter to allow for the height of the text either being
selected or the height of the caret at the insertion point. This will be
reflected in the next draft.

> >> Perhaps a some optional parameters such as cursor type (I-beam,
> block, etc.), orientation (vertical, horizontal LTR, horizontal
> RTL), and maybe language/locale (Are there any language- or locale-
> specific cursors? I don't know.)
> >
> > - Why does it matter what type of cursor is drawn? Were you
> looking for some additional functionality to drive a screen reader?
> This would be a new requirement. Also, we are not asking the system
> to draw cursor and the canvas 2D context API does not have an API
> for configuring the cursor which leads me to believe this is handled
> outside the canvas API and can be processed by normal accessibility
> API mapping by the browser. I would want to hear from Microsoft to
> see if this is something that they also want this for Windows. Mac
> and Windows are different and I am not sure we can get a matching
> set of system caret/selection types. I am thinking we could do
> without this functionality.
>
> That suggestion was intended for discussion and I'm willing to drop
> it if it's deemed unnecessary. Hence the words, 'perhaps',
> 'optional', and 'maybe'…
>
The group in attendance resolved to not include this feature at this time.

> Cheers,
> James
>