RE: html5 editor responds to Canvas accessibility related bugs

On Sun, 26 Sep 2010, Frank Olivier wrote:
>
> Ah...I see your point.
> 
> Let's scope this: Canvas usage can be categorized as:
> 0 - Decorative use - no actual information is communicated
> 1 - Non-interactive canvas - 'read-only' information
> 2 - Interactive canvas - 'UIs'

There's also a fouth category: interactive canvas that is implementing 
something that is better done using more accessible dedicated means.


> Usage 0 (Decorative use) generally would not require any accessibility 
> considerations (For example, let's say I draw a 'visual fluff' animated 
> background.)

Agreed.


> Usage 1 (Non-interactive canvas) is something that the change proposal 
> for Issue 74 
> (http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibilitynonav) 
> is well suited to - the screen reader would see a table instead of a 
> graphical chart in this scenario. (This is implemented in Internet 
> Explorer 9 beta today.)

Agreed, except that the change proposal isn't needed for this -- the spec 
already requires this. (The change proposals provides a redundant way to 
disable this, making the fallback content inaccessible, which is the 
opposite of what is needed to make usage 1 accessible.)


> Note that this puts an additional (unavoidable) burden on the author; 
> you have to provide the alternative representation with essentially the 
> same information as the canvas bitmap.

Indeed.


> The change proposals for Issue 105 provides a less optimal solution 
> here, IMO - the author may want to include more information that usemap 
> would be unable to provide.

Absolutely, image maps are a terrible solution to making <canvas> 
accessible.


> Usage 2 (Interactive canvas) requires that authors recreate a version of 
> their UIs to (a) report state to a screen reader (b) allow the screen 
> reader to change state. I believe that the change proposals for issue 74 
> easily addresses these requirements for most UIs, provided that the 
> authors can recreates their custom-drawn UI with standard UI controls 
> (radio buttons, etc) in the 'accessible' dom and keeps them in sync; see 
> attachment for an example.

Absolutely; there's even an example in the spec (for a pair of 
checkboxes). There is, however, a world of difference between a bunch of 
radio buttons and a text editor.


> For UI concepts where the user changes a control state (checkbox, radio 
> button) or invokes an immediate action (button, link) this maps very 
> well - of course, provided that the author keeps the 'accessible' dom 
> and the visual UI in sync. A bit of work, but not very hard.

Indeed.


> Ian, from your previous emails, can I assume that you are OK with the 
> *concept* of creating an alternative (for-the-screen-reader) 
> representation of the visual UI?

Not only am I ok with it, the spec requires it.


> So...
>
> "The discussion here is about something for which <canvas> isn't a valid 
> use case: making a text editor."
>
> Recreating a text edit control with canvas certainly is a daunting task; 
> even without considering accessibility, the author would have to do a 
> considerable amount of work to essentially rewrite/clone selection, copy 
> and paste, keyboard behavior - and would very probably be unable to wire 
> up some features - no built-in browser spell checking, no IME 
> (http://en.wikipedia.org/wiki/Input_method_editor), no autofill of form 
> entries.

Indeed.


> In this scenario, we will probably be better off instructing authors to 
> use actual text entry elements - and not to recreate them. I'm at a loss 
> to think of a scenario where an author would be limited by the actual 
> input text control.
> 
> However, we still need mechanisms to inform screen readers of UI focus - 
> for other non-text-entry UI controls.

The spec already has that.

This thread started when Steven linked to two bugs that were requesting 
APIs only useful for canvas-based text editor implementations: a way to 
report the caret position, and a way to report the selection area. The 
spec doesn't currently have such an API. Providing such an API would 
tacitly legitimise people making canvas-based editors, which I think we 
should avoid. But beyond that, nobody has yet proposed an API that would 
actually improve accessibility even if we decided that it was worth the 
cost of encouraging people to write canvas editors.

To create an API that actually improves accessibility, it has to:

 - be simpler to use than rolling one's own paint methods. Otherwise, 
   people will just go ahead and do their own thing and accessibility 
   needs won't be served. This essentially means you have to provide a 
   stalking horse. For example, drawFocusRing() does this by providing 
   several features unrelated to accessibility:
    - it does the focus check for you
    - it allows you to render the focus ring in the platform style
    - it integrates well with the path API

 - actually support the relevant native accessibility needs. For carets, 
   that means supporting blink rate control and supporting width control. 
   (I haven't researched what this means for selections.)

 - actually support the relevant non-accessibility needs. For carets, 
   this means supporting clipping at the edge, supporting positioning 
   relative to text positions, supporting scrolled text, supporting bidi
   positioning, supporting bidi carets, and supporting efficient blink 
   redraws. For selections, this means supporting text colour changes, 
   supporting bidi ranges, supporting clipping, relative positioning, and 
   scrolling as with carets, and supporting redraws that handle transluent 
   backgrounds.

 - be resilient to the kinds of mistakes Web authors will throw at this.

Doing an incomplete or inadequate job here will lead to the worst possible 
outcome: people thinking they have made accessible Web pages while _still_ 
not having done so. If there's no API, then at least people can be 
educated into feeling the need to provide an accessible version (which as 
a side-effect would likely be better for everyone, given how hard it would 
be to create a good text-based editor). If there is an API, they'll just 
say "well this is accessible, my work is done here", even if in practice 
their solution is still inaccessible due to mistakes in the use of the 
API. (For example, an API that simply reports the caret position without 
the use of a stalking-horse-like API to ensure that it is the real 
position would likely be given bogus coordinates in most cases.)

Finally, there is the opportunity cost. While we discuss, design, and 
implement an API that satisfies the above requirements, we could instead 
be working on features that would make it more likely that editors will be 
done without canvas. For example, we could be inventing APIs to make 
contentEditable and <textarea> have incremental syntax highlighting -- 
that would make using those features much more attractive than using a 
canvas, and would result in a relative increase in the accessibility of 
the Web. Effectively, even discussing an API for carets and selections 
could be argued to be harmful to the Web's accessibility.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 September 2010 02:24:03 UTC