RE: html5 editor responds to Canvas accessibility related bugs

Rich Schwerdtfeger
CTO Accessibility Software Group

public-canvas-api-request@w3.org wrote on 09/26/2010 09:23:33 PM:

> From: Ian Hickson <ian@hixie.ch>
> To: Frank Olivier <Frank.Olivier@microsoft.com>
> Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
> Date: 09/26/2010 09:27 PM
> Subject: RE: html5 editor responds to Canvas accessibility related bugs
> Sent by: public-canvas-api-request@w3.org
>
> 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.
>

Yes, but you indicated to me in discussions on irc in the WhatWG that this
was not worth the effort.

You also asked me to create defects against the 2D API to create a caret
and selection API to handle all this. In fact you told me that I should not
try and create an API to drive magnification but to simply write a defect
against the 2D API. So, I did this.

So, I see a lot of diversion going on here. Make people go do busy work
that you then turn around and ignore. So, you have those defects created
yet I have seen no movement on your end. Sounds like you know what is
needed.

Believe it or not Windows has an API that draws and tracks caret
position. ... Bidi would be handled by editing author. An inverting caret
could deal with high contrast issues.  It is not the systems job to change
the caret color with a text color change.

Regarding clipping, I would hope that canvas has internal clipping
capability. When setting the caret position an author would do it relative
to the canvas whose position would then be relative to the top of the
document and compensated for by scrolling. Everything drawn in the <canvas>
is relative to the canvas rectangle.

> 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.   `._.-(,_..'--(,_..'`-.;.'
>