Re: hit testing and retained graphics

On 7/8/2011 12:02 PM, Tab Atkins Jr. wrote:
> On Thu, Jul 7, 2011 at 7:55 PM, Jonas Sicking<jonas@sicking.cc>  wrote:
>> If we instead take the examples that I listed in my email and analyze those:
>>
>> "pie charts"
>> It seems to me that simply requiring screen readers to read the DOM
>> contained in the canvas goes a long way here. The author can then put
>> the same data as is being displayed in the chart in a<table>  which is
>> read to the user. This isn't really falling into the category of
>> "interactive" which you asked about though.
> Doing<canvas><table>...</table></canvas>  is acceptable, but it's even
> better to draw the pie chart in SVG, so you can do things like attach
> descriptions to the slices.
We can do the same in canvas by swapping the title tag and other such 
methods;
we have parity for keyboard control, and within the browser, we've got 
title=""
methods for mouse over, as well as any other method we like to display
something when the mouse moves.

We can also "export SVG" so the user can download an SVG interpretation,
we can also go ahead and do-both; a sometimes better solution for 
compatibility.

The one thing we can not do is let the AT know about descriptions in a 
manner
that does not "set focus". We can let the AT know, but we will have to 
run a .focus()
event. That's not acceptable as we're not supposed wrestle with the user 
over
element focus.

>> "angry birds"
>> I honestly have no idea. Suggestions welcome.
> It's not possible in general for games, I think.  You have to
> specifically engineer new interaction modalities to to address
> ability-limited situations.
I don't like this kind of talk, Tab. It's disrespectful to developers 
and users.
You are not qualified to tell us what is possible with game accessibility.

As for "new... modalities", that's something that engineers and users
are looking at all-the-time. As developers and in my limited role in
addressing spec issues, I'm doing my best to make sure they have
a better chance of succeeding.


>> input[type=checkbox]:not(:checked) {
>>   content: -moz-element(#checkboxchecked);
>> }
>> and so on. See [1] for a full feature description
>>
>> I believe webkit has a similar feature. Obviously all parties need to
>> agree on a single solution here so that we can deploy non-prefixed
>> properties.
> The 'content' property needs another knob to make the image act like a
> replaced element (dbaron suggested just using a 'replaced' keyword
> alongside an image to change the behavior).  But otherwise, yeah,
> that's exactly right.  I have the element() function specced in Image
> Values as well.
This still is not "automatic" as pixel ratios need to be taken into account.
I'm happy that -moz-element and WebKit's getCSSContext are around, 
they're good to have.

They're not the topic.


>> "rich text editing"
>> I think that the only good solution here is to severely improve
>> contentEditable. Currently contentEditable is a pain for authors to
>> use because it doesn't provide a low level API, only high-level things
>> like execCommand. It also works dramatically different in different
>> browsers and with lots of different bugs in all browsers. It's really
>> quite terrible. It's not surprising that some developers have said
>> "screw it" and attempted to do better using canvas.
>>
>> There's been some ideas floating around within mozilla for what type
>> of API we should expose, but so far no one has had the time to
>> prototype anything. I really think this needs to be made a higher
>> priority on the web platform in general. Not just to make text editing
>> more accessible for AT users, but for non-AT users as well.
> Agreed here.  Trying to do rich text editing in canvas is just such a
> horrible idea.  It's really the worst.  People will continue trying to
> make it work, and they'll continue failing horribly and going back to
> letting the browser handle most of the pain.  We just need to make it
> easier to do that, as you say.
Computers are not some magic box that you and a handful of other browser 
vendors
have exclusive knowledge over. This elitism has been the most disappointing
and disillusioning experience I've had in coming to the WHATWG and W3C 
with issues.

It truly saddens me, the manner in which you and others wield power.
It's the same let down: developers will "do it wrong", that you and 
others will "do it right".

I can look at a long history of browser vendors doing it wrong, and I 
can look
at the support that I've been able to develop to "do it at all". I work 
to support a much
wider audience than you do. I still try to support older computers.

I do -not- understand why you have such credibility as to tell me that I've
failed horribly at undertakings. I've been quite successful in bringing 
WebApps to
more platforms.


-Charles

Received on Friday, 8 July 2011 20:50:28 UTC