Re: hit testing and retained graphics

On 7/8/2011 2:32 PM, Tab Atkins Jr. wrote:
> 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;
...
>> 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?
Yes, that's correct. The part that involves wrestling for focus has to do
with the existing state of Canvas. I was replying that we can do exactly
what you're talking about in your SVG example, in Canvas as well.

With one exception: We can not tell the AT that the pointer is over
a particular element. We can only do that if we run element.focus()
while the pointer moves.

That's why we need a method for expressing that data.

>
>>>> "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?
Yes, I wish to correct you. Gamers with disabilities have shown that 
it's possible
to play many games. I know that several examples were brought up earlier 
in the list
relating to classic games such as Pac-Man.

Tactile interfaces, such as those built for seeing with the tongue, are 
able to convey
reasonably high resolution to the user.

Non-tactile interfaces, such as audio, are also able to convey spatial 
properties.

We've previously discussed this thread of "possibilities":
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0092.html

It's a hot issue, to come out and say that it's not possible, in 
general, for games
to be accessible. Engineers can build alternates for people non-visual 
sight,
and gamers themselves are quite adept at adapting with the senses they
have available.

I hope in time, you come to understand why your statement about
"possibility" is controversial.


>> 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.
I worked on a Canvas RTE to address minority languages and situations where
the user has a cognitive disibility.

I'm working on this spatial awareness issue [ setElementPath ] to target
tactile / gesture devices as well as ATs which inspect the DOM then provide
visual cues.

setElementPath would certainly work with a tactile display. But right now,
I'm focused on getting Apple's VoiceOver on Mobile Safari working well.

Their innovation in Mobile AT is something I really admire and I think
it's something that other vendors will follow.


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

I want my code base, and the hundreds to thousands of other code bases
which use canvas, to be accessible. We have dozens of ways to make 
prettier checkboxes;
the current example for drawFocusRing in the HTML spec is a checkbox.

I want to support an ARIA+Canvas profile.


-Charles

Received on Friday, 8 July 2011 21:47:14 UTC