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

On 7/1/11 2:24 PM, Tab Atkins Jr. wrote:
> On Fri, Jul 1, 2011 at 11:08 AM, Charles Pritchard<chuck@jumis.com>  wrote:
>> 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.

This is actually not the case in Gecko in some cases; I can't speak for 
the others.  c.f. https://wiki.mozilla.org/Platform/Features/AzureD2DCanvas

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

Again, this may or may not be the case.

>> You can see this when you boot up a11y monitors; the
>> vendors only use the OS provided widgets for the url
>> bar

And in Mozilla's case not even that.

But note one important issue here: web specs demand behavior from 
in-page GUI widgets that is simply not possible with the OS provided 
ones in many cases.

Of course the argument could be made that web sites may want behavior 
(perhaps because the graphics designer demanded it) that is simply not 
possible with browser-provided widgets.

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

Uh... You wouldn't?  This happens all the time.  People criticize 
decisions to use "non-native widgets" that look wrong, behave wrong, are 
slower than native ones, etc, etc.  I've heard such criticism applied to 
at least GTK, Qt, XUL, Swing, SWT, wxWidgets, and the in-page controls 
provided by all the major browsers.  And I haven't been listening very hard.

It's taken browser developers several person-decades each to get what 
they have now (which as you point out is still imperfect).

>> Somehow, several developers on this list think that
>> criticism is appropriate for web application developers.

It is.  Just as it's appropriate for desktop application developers. 
They may have their reasons for doing it (or think they do), but that 
doesn't necessarily mean they're right.

And unlike the widget toolkit projects listed above they do NOT plan to 
put in the time to fix issues that arise, by and large.

I appreciate that they may do custom widgets anyway, and that we should 
try to make it possible for them to make them accessible if they want 
to.  But we should also think about how to make making things accessible 
_easy_ so it's the default behavior.  For a start, perhaps more 
flexibility in the browser-provided widgets?

-Boris

Received on Friday, 1 July 2011 19:08:19 UTC