Re: hit testing and retained graphics

On Thu, Jul 7, 2011 at 7:12 PM, John Foliot <jfoliot@stanford.edu> wrote:
> Jonas Sicking wrote:
>>
>> Sorry for replying to an old email here, but this sat in my "drafts"
>> folder and I figured I might as well send it.
>
> Hi Jonas,
>
> I'm pretty much staying out of the larger discussion, but you raise some
> interesting points.
>
>>
>> For what it's worth, I don't think the disconnect is in if we should
>> start with use cases or not. I think the disconnect is between what
>> type of feature we're designing and thus the use cases are.
>
> I also think that part of the disconnect is in seeing accessibility
> capabilities as a "feature" rather than a foundational requirement. It
> seems that with <canvas> we unfortunately missed that need in the initial
> deployment phase, so now (it appears to me) we are left with trying to
> retro-fit a solution in place. I can appreciate the desire for elegant and
> easy solutions, however I don't think we will find one here: Retrofits are
> rarely easy, and often quite messy, which is also what I think is
> contributing to the discussion.

I think we're always avoiding adding accessibility as a "feature".
Which is why we're pushing people to use <button> instead of <div
onclick="..."> as the former contains accessibility built in, whereas
the latter requires adding accessibility features such as aria.

At least I haven't seen anyone doing otherwise.

>> Or, put another way, when working with accessibility for computers, we
>> don't try to attack the problem "how do we make computer displays
>> accessible", we attack the problem "how do we make microsoft word
>> accessible, how do we make the OSX file system browser accessible".
>
> Fair enough.
>
> How do we make *interactive features* that can be created using <canvas>
> accessible?

Well, so this is again repeating the same question as before, which is
one that I don't think can be answered. You're basically asking "how
can we make interactive programs displayed on a computer display
accessible" rather than "how do we make interactive program X
accessible".

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.

"angry birds"
I honestly have no idea. Suggestions welcome.

"fancy checkboxes"
Ideal would be if CSS had more power here to make it possible to style
the checkbox directly, rather than having people use canvas. For
example if browsers would implement the 'content' property on
non-pseudo-element selectors this would likely go a long way. That way
people could do things like:

input[type=checkbox]:not(:checked) {
  content: url(unchecked.png);
}
input[type=checkbox]:checked {
  content: url(checked.png);
}
input[type=checkbox]:not(:checked):active {
  content: url(activeunchecked.png);
}
input[type=checkbox]:checked {
  content: url(activechecked.png);
}

For sites that didn't want to use a static image but rather a
generated canvas, something like the -moz-element value should work
quite nicely:

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.


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

[1] https://developer.mozilla.org/en/CSS/-moz-element

/ Jonas

Received on Friday, 8 July 2011 02:56:50 UTC