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

On Mar 13, 2010, at 9:26 AM, Richard Schwerdtfeger wrote:
> 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.
>
> <Rich>When text is selected it is usually following the caret  
> position. Accessibility APIs that I work with drive focus by  
> following the caret positon. For example, click and hold your mouse  
> on the email you are writing and then drag. When you click and hold  
> the caret is moved to that location. When you then drag the caret  
> moves with the selection and finishes up where you release. The  
> magnifier should follow the caret.
>
At least on Mac OS X, the visual results are that the caret disappears  
as soon as I start dragging, and a selection appears instead. When I  
stop dragging, the caret does not reappear. Instead, a selection  
remains. To the best of my knowledge, this also matches what happens  
in the DOM -- you either have a caret selection or a range selection,  
not both at the same time. The caret is a special case of the  
selection, in the case where the selection start and end points are  
the same. This also also matches how carets and selections are treated  
in Mac OS X system APIs. I don't have Windows handy right now to test,  
but I don't recall ever seeing a caret and a selection appear at the  
same time.

Maybe I'm misunderstanding what you are saying.
> Here is the caret move event from IA2:
>
> http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_event_id_8idl.html#e26846b6d521727ab696d20c3f43c0b51d10f0c96c8c085baa648f166866d8c1
>
> When selection changes it is usually for a range of text. So, really  
> when you are selecting text you should be following the caret or  
> point of regard. This would then need to be synched with the caret  
> location in the DOM sub tree.
>
I don't follow. What's the "point of regard"? How can you follow the  
caret when selecting text, if there is no caret when selecting text?

In the API you linked, there appear to be separate TEXT_CARET_MOVED  
and TEXT_SELECTION_CHANGED events. That implies to me that changes to  
both need to be reported, and that the appropriate one would be sent  
depending on wether the selection is currently a caret.

>
> So canDrawCustom really means something like  
> wantToDrawCustomUnlessSpecialFocusRingSettingIsInEffect, but that's  
> a bit verbose. Perhaps there is a different good short name for the  
> parameter.
>
> <Rich> I recommend we change it to requestDraw and add the caveats  
> you indicate ... The default would be false which would leave the  
> drawing up the user agent to draw the focus ring. If it is true the  
> author is requesting to draw the focus ring. The drawfocusring  
> should return a boolean attribute to indicate to the author that  
> they may draw the focus ring. If the drawFocus method returns false  
> it indicates to the author that the user agent has decided to draw  
> the focus ring due a user experience setting such as for a high  
> contrast focus ring. </Rich
>

requestDraw sounds like it would have the opposite of the intended  
effect (i.e. request that the UA should draw the focus ring, always.)  
The boolean return you suggest is in the draft already.


Regards,
Maciej