- From: John Foliot <jfoliot@stanford.edu>
- Date: Fri, 8 Jul 2011 12:15:08 -0700 (PDT)
- To: "'Jonas Sicking'" <jonas@sicking.cc>
- Cc: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, <public-canvas-api@w3.org>, <public-html@w3.org>, <public-html-a11y@w3.org>
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