Re: change proposal: Provide accessibility implementation information (in the Canvas 2d Context specification) for focus rectangle and caret

On Mar 11, 2010, at 7:43 AM, Richard Schwerdtfeger wrote:

> Hi Maciej,
>
> First, this is great feedback. I tried to stay in line with what was  
> in the 2D Context draft that was out there, which in the fine print,  
> indicated that the focus rectangle was also used for caret. It was  
> unclear how much of the drawFocusRing() was implemented and I tried  
> not to break things. So, I also had problems with reusing the same  
> method.
>
> Here is the the text in the existing text that I am referring to:
> "The position of the center of the control, or of the editing caret  
> if the control has one, should be given in the x and y arguments."
>
> So, it appears you are in agreement with simply having caret API  
> that says setCaretPosition with a set of coordinates. As it states  
> it would be bound to an element in the subdom which has a logical  
> character position which the author would synch with. This we have  
> in the proposal. I will simply separate them out.
>
Why setCaretPosition rather than setSelectionPosition? It seems to me  
that screen magnifiers or the like may be interested in the screen  
location of non-caret selections too.
> Second, if we require the author to do all the caret drawing I see a  
> problem with not honoring blink rate settings that the author does  
> not have access to. If the blink rate is high enough (greater than 3  
> times a second) this may call seizures in some users. Should we not  
> provide the ability for the user agent to override the drawing in  
> some way?
>
We may have to expose the blink rate. I think it would be hard for the  
UA to properly handle the blinking, because in general content may  
overlap the caret, but canvas has no data model other than a bitmap.  
For carets in native controls, the UA has to ensure that overlayed  
content is drawn over the caret, but in the canvas case, it would be  
the responsibility of the Web content.


>
> Third, what I and others are struggling with is canDrawCustom on  
> drawFocusRing():
>
> "If the canDrawCustom argument is true, then the focus ring is only  
> drawn if the user has configured his system to draw focus rings in a  
> particular manner. (For example, high contrast focus rings.)"
>
> This does not make sense. The parameter, my name, indicates that the  
> author can draw a custom focus rectangle. It would make more sense  
> to say that the focus ring is drawn, by the user agent, only if the  
> user has configured the system to draw focus rings in a particular  
> matter. ... meaning the user has configured the desktop to draw  
> focus rings in a standard way and the author should not override  
> that. Do you agree?
>

canDrawCustom is a bit of a funny name. I believe the intent of the  
parameter is as follows:

- If canDrawCustom is false or omitted, the UA takes care of drawing  
the focus ring, no matter what. This is the simplest form of the call  
to use.
- If canDrawCustom is true, then the Web application is indicating its  
intent to draw the focus ring in a custom way; but if the UA would  
draw focus rings in a way that respects a special accessibility  
setting, such as high contrast, then it still does the drawing. The  
Web application can tell whether it should do its custom focus ring  
drawing from the return value.

So canDrawCustom really means something like  
wantToDrawCustomUnlessSpecialFocusRingSettingIsInEffect, but that's a  
bit verbose. Perhaps there is a different good short name for the  
parameter.

Regards,
Maciej