W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Re: Accessibility, perfect or better Re: hit testing and retained graphics

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 01 Jul 2011 11:08:56 -0700
Message-ID: <4E0E0D38.2050900@jumis.com>
To: Charles McCathieNevile <chaals@opera.com>
CC: "E.J. Zufelt" <everett@zufelt.ca>, Paul Bakaus <pbakaus@zynga.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, Frank Olivier <Frank.Olivier@microsoft.com>, "Mike@w3.org" <Mike@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On 7/1/2011 7:41 AM, Charles McCathieNevile wrote:
> On Thu, 30 Jun 2011 15:52:52 +0200, Paul Bakaus <pbakaus@zynga.com> 
> wrote:
>> Am 29.06.11 15:50 schrieb "E.J. Zufelt" unter <everett@zufelt.ca>:
>>> On 2011-06-29, at 9:33 AM, Paul Bakaus wrote:
>
>>>> …Mostly, today's canvas applications are game demos and drawing apps.
>>>>
>>> What about tomorrow?
>>>
>>>> If you are writing your GUI in canvas, you are doing it wrong...
>
> (Agreed. That doesn't mean it won't happen) 

Seen this one a few times, it's never made sense to me.

All of the browser vendors use the same underlying graphics libraries to 
power canvas
as they do to power their GUI/render trees. It's the -same- code paths.

The difference in GUI is that one is written by a vendor, and compiled 
via C++ (typically),
and the other is written by a developer, with JIT compilation from 
ECMAScript (typically).

Even in ECMAScript, the code path still connects to the Render Blocks; 
it still passes
through the CSS processing tree.

You can see this when you boot up a11y monitors; the vendors only use the OS
provided widgets for the url bar, and some debugging. Other components are
rendered by their low-level graphics libraries [the ones that take a 
path and
fill/stroke the path, then composite]. In many cases, it's the url bar that
functions best in a11y, and the rest of the components area  mixed bag.

The same applies, in some sense, to developers and their relationship 
with vendors.
Devs decide that they're going to use their own css styles, and their 
own menus,
instead of leaving it to the default rendering of each browser.

In some cases, this means that the developers inadvertently exclude items in
when the user has set their OS to high contrast mode.

So, there you have the UA vendors treating the OS in a manner similar to 
developers
treating the UA, with similar pitfalls.

If you're writing an application -- you're an application developer. I'd 
never
expect to hear someone criticize a desktop application developer for 
creating their
own buttons, and writing their own widget library. Somehow, several 
developers
on this list think that criticism is appropriate for web application 
developers.

I'm with Doug's statement on his proposal: it's a false dichotomy.

But gosh, I'm a little frustrated here, when, we have actually 
measurable code paths,
that can be inspected and referenced, we have specs that prove 
equivalency. And still,
we have vendors and other developers saying that one side of the 
equivalency is "wrong".

ARIA semantics and/or the shadow dom provide for technical equivalency with
OS-level UI components:

<canvas tabindex="0" role="button"></canvas> == <button 
tabindex="0"></button>
== <canvas><button tabindex="0"></button></canvas>

Canvas semantics with CSS attributes provide for equivalency with the 
UA-level elements
in the render tree.

You're not "doing it wrong", when you are using the very technology that
the browser runs on, and using the DOM/HTML semantics that the web users.

When you're following the standards, using standard APIs, you're doing
application development "right".

-Charles
Received on Friday, 1 July 2011 18:09:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:31 UTC