RE: hit testing and retained graphics

Jonas Sicking wrote:
> 
> 
> I think we're always avoiding adding accessibility as a "feature".

Hi Jonas,

I think that conceptually this is true - nobody is deliberately saying
"forget accessibility", and I am not pointing fingers anywhere, however
there is also a disconnect between the goal of being accessible and
inclusive, and what we actually see emerge from busy developers and shops
who occasionally are weighing multiple deliverables, short time-lines, and
to whom "accessibility" sometimes remains a somewhat abstract term... it's
like "peace" - everyone is for it but sometimes we forget when we raise
our voices, give that jerk in the next car a finger for cutting us off, or
demonstrate other flashes of our humanity. I think very few of us are
truly "peaceful" all of the time - we need to work at it, and be reminded
of it at times, and need help achieving it.



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

LOL, Jonas, it's *me* - I am a *HUGE* proponent of semantic elements - I
still want <poster> remember?

I thank you for your efforts in pushing developers in this direction. But
we would both be pretty naive to suggest that developers will not continue
to use <div onclick="..."> or variants of this to recreate buttons - we
both know that the styling of <button> is problematic to the designers,
although it has gotten a lot better
(http://www.456bereastreet.com/lab/styling-form-controls-revisited/button/
).  

So while we *urge* people to use <button>, we must also account for the
fact that some won't, and so we have aria-role="button" - less elegant,
less "universal" in design, more complexity, more code, more work - but it
scratches an itch that needs to be scratched.

To me, we are in a similar situation with <canvas> today: we want to urge
devs to reconsider <canvas> for interactive designing, but some won't, and
so what is the less elegant solution to this problem: what is the "ARIA"
solution to the access issue that Rich and others have brought forth?


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

I suppose this is true, but in many ways the question does need to be
posed at that high a level as well. It seems that for every use-case we
can come up with now, there remains 5 or more that we cannot even imagine
today, but could be here with us tomorrow or next year - that is the
awesomeness of the web. I recall hearing that when <canvas> was first
specc'ed out nobody ever consider using it for text editing - until Bespin
came along that is.

So having a higher-level conceptual model of how to address the larger
question has value, even if that high-level model seems complex, less
elegant or unintuitive. We all agree (well, certainly I agree) that this
is sub-optimal, but so is using aria-role="button" on a <div> versus using
<button>. When I work with devs on campus, I call this "Plan B" - if Plan
A fails, what is your Plan B? If a developer uses immediate-mode graphics
"incorrectly" we can wag our fingers and say shoulda, coulda, woulda, but
that doesn't solve the immediate issue at hand: how do we retro-fit the
problem to make it accessible? Where's our Plan B? ("Go back to square 1"
is not a viable answer)


> 
> If we instead take the examples that I listed in my email and analyze
> those:

I'll start by saying that you have enumerated a number of choices below,
and I have always been a big fan of choice - the more choices we avail
developers, the more creative they can be, and the more opportunities they
may have to also ensure that what the wrought is accessible, or can be
made so. Choice is good!(TM)


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

Agreed, and there are currently solutions out there that do exactly this:
http://media.liquidx.net/static/canvasgraph/tests.html 


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

(I think suggestions are coming forward, and are being rebuffed)



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

I think that this is all great, but even you admit that we don't have much
if any of this today - so "people use canvas". Even if by the end of the
summer we had all of this in CSS3, in the browsers, and stable and robust
authoring tools to generate this code, it would only be solving one aspect
of the larger question - How do we make interactive <canvas> accessible?
It would go a long way in this situation (but still fails the "Angry
birds" scenario). When we get something like this, we'll have a new
"<button>"-like solution: elegant, simple, semantic, appropriate. But
until then, what is Plan B?


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

And it seems then that this is a major itch that needs scratching right
now - certainly not the only one, but a really big one. The fact that "...
some developers have said "screw it" and attempted to do better using
canvas" is the very reason why telling them "don't do it" has very little
traction - they don't have other choices right now. So faced with this
truth, the canvas accessibility folks are attempting to develop an
"ARIA-like" solution: sure it seems bolt-on, more complex, less elegant,
less intuitive... but solving the problem that needs to be solved, and
hopefully in a framework type of way that can be used for the next
unimagined cool thing in <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 I look forward to a successful Plan A solution, and more choice for
developers.


JF

Received on Friday, 8 July 2011 19:15:42 UTC