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. Regards, Maciej
Received on Monday, 15 March 2010 20:54:36 UTC