Re: html5 editor responds to Canvas accessibility related bugs

Hi Ian,

you wrote:
"Absolutely, image maps are a terrible solution to making <canvas>
accessible."

can you elaborate, sting its terrible , as you have said previously, without
providing any explanation, is not helpful.


regards
Stevef
On 27 September 2010 03:23, Ian Hickson <ian@hixie.ch> wrote:

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


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html