W3C home > Mailing lists > Public > public-html@w3.org > March 2010

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 15 Mar 2010 13:53:53 -0700
Cc: Steven Faulkner <faulkner.steve@gmail.com>, public-canvas-api@w3.org, HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html-a11y-request@w3.org, public-html-request@w3.org
Message-id: <05EF7908-7FED-4702-A746-5D388A0FD6CA@apple.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>

On Mar 15, 2010, at 1:07 PM, Richard Schwerdtfeger wrote:

> <RSS>I confirmed with Frank Olivier (Microsoft) that when you turn  
> on caret browsing the follows the end of the caret selection drag.  
> Also, on my Mac, although the caret does not render during  
> selection. If you drag the selection and then hit the right arrow  
> key the caret appears at the end of the selection. However, if you  
> hit the down arrow it goes to the next line at the X Position  
> representing the start of the drag. We need to have the screen  
> magnifier follow the end of the selection and even if the caret is  
> not visible I feel you want to follow the end of the select or caret  
> location. The caret, during a selection should follow the end the  
> selection drag. It does on Windows for caret browsing mode. The  
> Accessibility API used to move the "point of regard - a UAAG 1.0  
> term", on systems I work on do so by following the caret position  
> and not the selection which is a selection range vs. a location. I  
> can't see having the magnifier following a selection range as it  
> could be the whole page.
> </RSS>

I think it may not be obvious to Web application authors that they  
should expose the "end of selection" position as a caret position. I  
think an API that would be more clear is to for the Web content author  
to provide to coordinates for the start and end of the selection, and  
the UA can decide how to map that to accessibility APIs (it could use  
the start or the end, or do whatever else is appropriate with the  
given assistive technology). I think that's cleaner and more  
appropriate than expecting Web content authors to know that they  
should report the selection end as a caret position.

It also seems like this would allow both TEXT_CARET_MOVED and  
TEXT_SELECTION_CHANGED from IA2 to be handled by the UA.


Received on Monday, 15 March 2010 20:54:30 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:13 UTC