Re: HTML Canvas 2D Context API change proposal for magnifier focus and caret/selection tracking

Hi, Rich.

I have several questions/suggestions. I apologize if some of them are
dummy: I didn't follow discussion very hard.

1. It would be nice to define fallback's content. It's worth to have
section describing fallback's content and focus management inside of
it. If this term is defined somewhere then it makes sense to provide
hyperlink when it is used the first time.

2. "This method only draws the focus ring if the element is focused or
is a descendant of the element with focus" confuses me because if for
example the canvas represents HTML document within HTML form controls
then if HTML document is focused then focus is allowed to be drawn
around any form control (for example when fallback's content contains
HTML iframe or canvas element is treated as a document).

3. drawFocusRing description has wording "If the given element is
focused, " and I failed to find the second "if" for the case when
descendant of the element with the focus. Also "If element is not
focused or is not a descendant of the element with whose context the
method is associated" doesn't sound like inverse statement for "if the
element is focused or is a descendant of the element with focus". What
is "document descendant" in the "the given element is focused or a
document descendant of an element with focus"?

4. "The given coordinates (x, y) are relative to the upper left corner
of the canvas element. These coordinates are converted to screen
coordinates within the user agent. The user agent then combines the
converted coordinates with the drawing path for the focused element to
compute the bounding rectangle of the associated element in the
accessibility API for that element. " It's not clear with me how (x,
y) coordinates are combined with the drawing path. Could it be
described more carefully?

5. Should the element be drawn every time when drawFocusRing is
called? If not then how the element's path is associated with the
element? I keep in mind the case when user tabs through controls drawn
in canvas and drawFocusRing is called then how to find the path
associated with focused element.

6. In "If the user has configured the operating system to draw focus
rings in a certain way (e.g. high-contrast focus rings), or if the
drawFocusRing  argument is absent or false" the "drawFocusRing
argument" should be changed to "drawCustomRing argument" I think.

7. Does makes sense to have a method to draw a selection?

8. Does setCaretSelectionPos draw a blinking caret? If no and the
author should blink the caret himself then how can it erase the caret?

9. setCaretSelectionPos: "If the user resizes or moves the user agent
window the user agent report must reflect the revised point (x, y)
coordinates in the accessibility API mapping. ". Does it mean the user
agent should redraw the caret at new position as well?

Thank you.
Alex.


On Tue, May 11, 2010 at 5:43 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> I would like to have all user agent developers to please provide
> feedback/changes they would like to see made to the proposal by Monday so
> that I may make any necessary changes to the final draft for May 24, 2010 to
> submit for a straw pole vote on May 27 in the HTML accessibility task force.
>
> Frank Olivier is going through the proposal with a fine tooth comb and will
> submit feedback on Thursday in terms of how these changes will map to the
> Windows accessibility API. These simple changes can all be made in MSAA as I
> see it so they will also be applicable to Firefox. That said, I would like
> both David and Alex to review the comments from Frank and submit them to the
> list. There seems to be a gap on Linux that we may need to fill. I am not
> aware of an ATK API to have a magnifier track the caret screen position.
> This may need to be added.
>
> As for Apple I would ask Maciej to look the changes and say if it can be
> mapped in some way to the Mac OSX accessibility protocol either now or in
> the future and if there are any changes that need to be made to the
> proposal. I plan on wrapping this up next week.
>
> Frank indicated that the HTML working group may wish to tweak the API or API
> parameter names. Personally, that is not an issue for me as long as they are
> well documented which given the feedback I have as of today the changes made
> the API modifications clearer. Changes reside between <ZZ> and </ZZ>
>
> I know the HTML working group would like to wrap this all up quickly so I
> urge you all to review and provide feedback in the requested time frame.
> Here is the proposal with the attached changes in HTML format:
>
> http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0021.html
>
> There will be no Canvas Accessibility API meeting on Monday, May 17, 2010 as
> I am traveling but I will have access to email and look forward to your
> feedback.
>
> Best Regards,
> Rich
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group

Received on Wednesday, 12 May 2010 14:17:48 UTC