Re: html5 editor responds to Canvas accessibility related bugs

So, I agree with you Steve. The first time I mentioned <canvas> to an IBM
product team the first thing that came out of their mouths was "this is
great, we could use canvas to tied to existing HTML controls to draw their
own custom UI. Can you make that accessible?"

The reason we needed ARIA today is because some people in the HTML working
group were adamant that HTML would only be used for documents. Then
Netscape pushed JavaScript much the same way we will see <canvas> being
pushed. While I appreciate what Ian wants it is not connected with what
really happens.

To give an example, the table element states that tables "must not" be used
for layout, yet I will tell you that custom UI components use tables for
just this purpose because browsers do not match layout the same way across
browsers and authors require this functionality. Second, there are millions
of database applications that use tables for layouts. All this code is not
going to be rewritten over a religious debate. Third, it is an
unenforceable requirement. You cannot tell with one hundred percent
certainty that tables will be used for layouts. Screen readers have tons of
code in them to try to guess if tables are being used for layouts. They do
not get it right all the time  as they have admitted to me. They will tell
you that they do a really good job - but that is it.

Unfortunately, accessibility requires the tools to allow the author to
annotate markup in the event that an author does things like use canvas for
editors. The difference between our perspective and Ian's is

- Ian can say why did that person waste their time doing something so
stupid! Tell the person that there is a better way.
- When a disabled user encounters the problem can't do their job and in
this economy it may mean they lose it. The Web is too big to run around
with the HTML 5 bible and bang all these web application developers over
the head with the HTML 5 bible.

We can certainly suggest that authors do something the right way as Ian
suggests but frankly that is nothing more than a recommendation.

So, if we are not given the tools to address this problem - as we did with
the JavaScript problem we have another need for ARIA situation on our
hands. This came at a huge cost in time and dollars to IBM. If we are not
given the tools we need to address this issue (a bible will not work) I see
this as an HTML 5 last call blocking issue.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Charles Pritchard <chuck@jumis.com>
To:	Steven Faulkner <faulkner.steve@gmail.com>
Cc:	public-canvas-api@w3.org, Richard
            Schwerdtfeger/Austin/IBM@IBMUS
Date:	09/25/2010 04:11 PM
Subject:	Re: html5 editor responds to Canvas accessibility related bugs
Sent by:	public-canvas-api-request@w3.org



This seems to round-up Ian's current sentiments:

"In practice it may make more sense to stop people from wasting their time
writing editors in <canvas>, which is not what <canvas> was for, and indeed
makes little to no sense."

Personally, I think that <canvas> sets forward a standard 2D API
for HTML elements to be implemented in. But that's clearly not where Ian is
at this point.

-Charles


On 9/25/2010 12:03 PM, Steven Faulkner wrote:


      Bug 10248 - Canvas requires a Caret Drawing call method
      Bug 10249 - Canvas requires a content selection method

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