W3C home > Mailing lists > Public > public-html@w3.org > June 2011

Re: hit testing and retained graphics

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 30 Jun 2011 10:21:01 -0700
Message-ID: <BANLkTikiBT0Vu_pobOZq9DSkMLo3qO2StjJkXNZtUNBNf8eEfQ@mail.gmail.com>
To: Matt May <mattmay@adobe.com>
Cc: Cameron McCormack <cam@mcc.id.au>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On Thu, Jun 30, 2011 at 9:58 AM, Matt May <mattmay@adobe.com> wrote:
> Frankly, I think everyone is getting hung up on the graphics mode. The graphics mode hardly matters. The vast majority of accessibility work does not occur at this level, but rather at one level back, in the object model that draws the graphics. But that doesn't stop anyone from doing the work to say, when I draw this rectangle and then I draw this line inside it that changes color from black to white once per second, then I have created a text field. How such a framework does that is immaterial, as long as it knows those five vectors now mean "text field". It is from there that accessibility hooks can be inserted: role, state, value, size, position, name, description. It's still possible to draw all kinds of bits on the screen without a real model for them, but nobody here is arguing for each of them to have an accessible name. We only want the ability to create a programmatic structure so that we can query and interact with when there is structured data (namely, UI components and things like charts) being presented as canvas content.

It appears you may be slightly confused about your terminology.  You
just defined a retained-mode API - the fact that those five vectors
stick around as things you can refer to automatically implies you're
working in a retained-mode API.

I also want to point out that the example of "make a text field
accessible" is one of the *worst* examples to use for the approach
taken here.  As I've pointed out in the past, a text field is *far
more* than just its position and value (or even the fuller set of
attributes you list).  An accessible text field must also, for
example, handle IMEs and properly format bidi text.  This is, once
again, why you must list your problems before attempting to solve them
- when you do, you realize that anything which just cares about the
position and value of a text field for the purpose of mapping clicks
or presenting to screen readers is an incomplete solution.

(I'll note that textboxes in Flash are generally horrible.  I dunno if
there's a *right* way to do textboxes in Flash, but people do them
wrong *so often*.)

~TJ
Received on Thursday, 30 June 2011 17:21:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:33 GMT