RE: html5 editor responds to Canvas accessibility related bugs

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'

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

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.)
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.
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.

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. 

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. 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?

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.

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. 

-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch] 
Sent: Sunday, September 26, 2010 12:50 PM
To: Frank Olivier
Cc: public-canvas-api@w3.org
Subject: RE: html5 editor responds to Canvas accessibility related bugs

On Sun, 26 Sep 2010, Frank Olivier wrote:
>
> IOW 'Why will people make accessible canvas elements?' 

No, that's not at all the question. There are lots of use cases for which <canvas> makes sense, and for which it makes sense to expose an accessible alternative, and so on.

The discussion here is about something for which <canvas> isn't a valid use case: making a text editor.


> Quite frankly, 'Why?' is not a question that we (the engineers) will 
> have to answer.

It absolutely _is_ a question we should ask, because if the answer is 
"they won't", then we shouldn't spend time designing an API.


> Our responsibility is to ensure that authors have a mechanism for making 
> canvas UI accessible.

No, our responsibility is to ensure that authors have a mechanism for 
making Web pages accessible. If an author decides to misuse technology, it 
is _not_ our responsibility to provide them with band-aids so that they 
can pretend to have done a good job after all.


> Who will ensure that web pages (with canvas UIs) are accessible? Quite 
> frankly: this is not a problem that just (we HTML5) engineers can solve; 
> just like with today's web, the people that create and use the web will 
> have to prioritize/demand accessibility.

I strongly disagree. It's our responsibility to make the Web accessible. 
It's of no use for us to invent technologies that can theoretically be 
made accessible if nobody uses them to make the Web accessible. We have to 
make sure that the technologies we invent are either automatically 
accessible (like most of HTML), or, when that's not possible, that they 
are so easy to make accessible that authors actually _want_ to do it, 
without having to be badgered into it by legal threats and government 
policies and so forth.

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