Re: hit testing and retained graphics

On Fri, Jul 8, 2011 at 1:49 PM, Charles Pritchard <chuck@jumis.com> wrote:
> 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.

Huh?  This doesn't make sense.  If you have something that links an
area on the image to a description, then focus doesn't have to enter
into this at all.  The AT can read and understand the linkage and deal
with it itself.  Writing the SVG something like this:

<svg>
  <g>
    <desc>[something about one slice]</desc>
    <path ...>
    [more code to display the slice]
  </g>
  ...
</svg>

Then the user can point at a slice and the AT can retrieve the
description.  The AT can read the code and proactively determine that
the slices have a description, and indicate that to the user somehow.
What part of this involves wrestling with the user for 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.

I'm a developer and a user.  I'm qualified to tell you what I think is
possible.  I'm also very willing to be corrected.  Do you wish to
correct me?


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

What new interaction modalities are you trying to address?  If the
answer is "whatever devs come up with in the future", we can't solve
that problem.  Designing for unknown future problems virtually always
fails and saddles us with bad API that we have to keep supporting for
legacy reasons, even though everyone knows it's bad.


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

They most certainly are.  Jonas brought up a concrete problem - "I
want to make a prettier checkbox that still works like a checkbox".
CSS has a viable solution that should be available in the near future.
 If you dismiss CSS because you're "trying to solve canvas
accessibility", *this is the issue I keep harping on*.


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

We are trying to solve problems for the web.  Web browsers are
currently the most relevant piece of software that these problems are
expressed on.  I also don't believe it's worthwhile spending time and
effort on solving problems for old technology.  We design for the
future, and deal with legacy issues when we're forced to.

I can't help your disillusionment, sorry.

~TJ

Received on Friday, 8 July 2011 21:33:16 UTC