- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 30 Jun 2011 10:21:01 -0700
- 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 UTC