Re: html5 editor responds to Canvas accessibility related bugs

  On 10/7/2010 11:44 PM, Benjamin Hawkes-Lewis wrote:
> On 8 Oct 2010, at 04:14, Ian Hickson wrote:
>> if someone can come up with a way to
>> make an API for these features that addresses the needs I listed (which,
>> based on past experience with accessibility APIs, would likely be the
>> minimum necessary to actually improve accessibility on the Web for pages
>> whose authors write their own editors), and assuming that browsers would
>> be willing to support them, then there's no question that we'd add them to
>> the spec.
> Does anyone have any specific API proposals to put on the table to resolve Bugs 10248 and 10249?

Let's go back to requirements for those APIs, and a road map.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10248

Ian's requirements are that a new API: (a) satisfies the accessibility 
use cases (blinks according to the system rate, draws the caret at the 
OS-set caret width, etc), (b) is sanely usable (handles clipping
around the edge of a control, handles scrolling of a long text control 
in a small field, etc), and (c) is easier than just hand-rolling a 
custom caret painter.

I've an objection to item (c). The point here is not to replace 
hand-rolled carets, it's to agree on a standard API, to communicate 
information about the caret position on the screen. This is mirrored by 
Richard's sentiments: "For now I am perfectly willing to have an API 
that drives magnification".

As an implementer, I'd like an API that I can use in addition to my 
hand-rolled caret painter.

We've established [correct me if I'm wrong] that this is not restricted 
to text editing, and that the following statement is incorrect: "This 
thread started [with] APIs only useful for canvas-based text editor 
implementations: a way to  report the caret position, and a way to 
report the selection area".
http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0028.html

What we're looking at, is "caret browsing", or "caret navigation":
http://en.wikipedia.org/wiki/Caret_navigation

Currently, Firefox and Internet Explorer implement caret browsing, but 
do not expose that fact to the scripting environment.

If there are objections to the prior statements, please refer to the 
above as "Section 1".

Let's continue this as Section 2.

At present, it seems that IE will check system settings for the caret 
width, where Firefox does not. It's reasonable to expect Firefox to 
support this as well: I am testing with FF 3.6, and have not tried their 
current development builds. Regardless, "caret navigation" semantics 
should be discussed more broadly: WebKit developers could use some help 
via the specs process.
https://bugs.webkit.org/show_bug.cgi?id=25526

Within the context of this forum, spatial navigation is even more 
complex, as it's not restricted to css line boxes.

The current drawFocusRing API is a good model for future work, as it 
provides "relevant native accessibility needs [and] non-accessibility 
needs".

It addresses most of the issues brought up by Richard and by Ian, in 
these conversations.

So lets look at what's lacking:

It seems to me that system rate blinking, caret width, and high contrast 
accessibility settings should be exposed to the scripting environment, 
perhaps through an extension to "window.navigator". Does this sound 
reasonable to everyone else? It would be nice to make those settings 
mutable, for the current page, so that the scripting environment may 
alter those settings as well as accessing them, under its local scope. 
If we can agree that this is handled outside of the canvas API, we know 
that hand-rolled canvas painters will be access such features. Mouse 
cursors are handled via CSS, it seems reasonable that a caret could be 
controlled via CSS semantics as well. Thoughts here?

Should the system caret be handled via CSS and its properties accessible 
by the scripting environment, hand-rolled painters will be able to match 
current OS settings and be adapted for content. I realize that this is a 
CSS proposal: canvas has a level of interoperation requirements with CSS 
already, it's a good relationship, and relevant to our discussion here.
style="caret: none" would disable the caret.
CSS Semantics: caret: none|url|auto width height blink-rate.
DOM: window.navigator.caretRate = 400; element.style.caretRate = 200;

drawFocusRing has opened up focus control, and the canvas sub-dom. It's 
fantastic. Other than semantic value, I don't know that it needs to be 
extended.

These could follow a similar structure; though the use of "element" as a 
parameter is questionable:
drawCaret, drawSelectionStart, drawSelectionEnd, drawFocusSelection.

drawCaret should accept directionality as a parameter. The usefulness of 
Start and End points for selection is clearly illustrated by touch-based 
selection mechanisms.

Are four options are useful, could use the existing path (with 
clipping), and could use x/y coordinate hints, for magnification/focus. 
They don't necessarily need an element parameter, and there would be 
issues with magnification, as we don't want a magnification window 
moving around as each method is called. Magnification positions should 
be calculation at the end of the event loop.

drawFocusSelection would simply outline the area we'd like selected, 
make our decision whether to use the canvas sub-dom or dataTransfer.

Let's call that the end of Section 2.

Is this a reasonable step forward? Are we in agreement about the items 
in Section 1?

As for Section 2: CSS / DOM support for caret management seems long 
over-due. I've shown that two vendors are actively supporting caret 
browsing, and that WebKit is struggling, but trying. This is obviously 
something to take up with the style list. I'd like consensus here before 
I bring it there.

Have we advanced at all from drawFocusRing with the draw* family I've 
proposed? I'd be happy to continue working on that family API, for focus 
management, but I want to know that my time is being well spent before I 
work out more details. I feel that I've engaged the CSS / DOM 
environment, as well as the browser event loop, in this proposal, and I 
hope that's sufficient for a nod, in continuing the work.

If there are ideas for different method names, let me know.

-Charles

Received on Friday, 8 October 2010 10:08:19 UTC