Re: Request to re-open issue 131

The HTML5 Editors draft uses scrollPathIntoView to accomplish the same thing as setCaretSelectionRect but with a broader goal and semantic. I've not been able to get its author to speak up on the issue...  They are both intended to fill in the caret tracking interfaces present at the OS level. These are used by zoom apps, but can also be used by heuristics in screen readers.

The HTML5 editor did not use the caretBlinkRate semantic. I have mixed feelings here. The blink rate is used by some screen readers as part of their heuristics. It's also managed by user preferences set on the OS level. It may be used to return a rate that's relatively safe for viewers that may otherwise suffer if the blink rate set by an author is too high. This semantic  is still useful for caret style navigation and indicators of where keyboard focus is, beyond a simple focus ring. But, it's difficult to generalize it further, as it seems the HTML5 editor would require.

If there are any ideas on how to salvage consensus on this maxFlashRate concept, it'd be nice to hear them. This is different than requestAnimationFrame use cases. This max flash rate is intended for on-screen position and progress indicators to help authors stay on the path to WCAG.



These APIs are based on system accessibility Apis for UI components of all types. There's no need to focus on text entry. There is a need to keep text legibility and tracking in mind.



On Dec 18, 2011, at 2:15 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> Are the methods proposed designed to facilitate the building of text
> editors in canvas? I think not, but clarification from Rich/Charles
> would be useful.

Received on Sunday, 18 December 2011 17:59:33 UTC