- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 14 Dec 2011 22:52:33 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Sam Ruby <rubys@intertwingly.net>, david bolter <david.bolter@gmail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>, dbolter@mozilla.com, franko@microsoft.com, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On 12/14/2011 2:02 PM, Jonas Sicking wrote: > On Wed, Dec 14, 2011 at 10:31 AM, Sam Ruby<rubys@intertwingly.net> wrote: > >>> At Mozilla there are certainly voices for avoiding any kind of >>> encouragement of canvas-for-text-app usage. >> It would be helpful if those voices were to participate here, on >> public-html. > In short, so far I'm not at all convinced that trying come up with > APIs that are solely for enabling text editors in canvas is worth our > or implementors time. > > This doesn't say anything about providing other accessibility-related > APIs for canvas though of course. For things like text selection and > hit testing I've seen more evidence both that we can create reasonable > experiences using various proposed APIs, as well as more of a need due > to how people use canvas on the web today. I'm afraid that I'm personally responsible for the cloud and confusion around these accessibility efforts: when I first noticed the text baseline issue, it was brought to my attention by one of my programmers working on an HTML-editing application written in Canvas. The subsequent issues I encountered were solely related to <button> implementations, but by that point, the damage had been done, and the conversation had turned sour. Since that time, I've worked quite a bit more in the area of accessibility, and I've tried to keep focus on issues with building widgets conforming to WCAG 2.0. I've seen no controversy about the validity of including baseline, and checkbox examples in the Canvas 2d specification. http://www.whatwg.org/specs/web-apps/current-work/images/baselines.png Proposed fix for the text baseline issue: http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline#Summary The Canvas 2d specification has been carrying <canvas><input type="checkbox" /></canvas> as an example for quite some time: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-ispointinpath The checkbox example is not sufficient to meet WCAG 2.0. Vendors are obligated to assess the issue per their own commitments to UAAG specifically, a requirement to provide: "Standard programming interfaces, to enable interaction with assistive technologies". Apple has shipped over two hundred million devices running iOS. Their recent versions of iOS have amazing potential as assistive devices, with the tightly integrated VoiceOver for Mobile Safari product. That product does not play well with Canvas. https://bugs.webkit.org/show_bug.cgi?id=63463 By simply using Apple's VoiceOver, and AISquared's ZoomText, we were able to demonstrate two mainstream programs that are crippled by the lack of accessibility APIs in the Canvas 2d specification. AISquared's ZoomText, requires caret positioning, Apple's VoiceOver on Mobile Safari requires defined regions. Apple's VoiceOver for OS X also uses caret positioning: https://dl-web.dropbox.com/get/Public/a11y-caret-position.png?w=3c525267 AViewer is an easy to use introduction to accessibility testing in Windows: http://www.paciellogroup.com/blog/2010/06/aviewer-beta/ This kind of accessibility work is very simple. One may simply open up IE9, and AViewer, and browse the accessibility tree. It's really simple stuff. While we've worked through hundreds of replies about Canvas use cases, the technical issue and the WCAG and UAAG documents have existed all along. Until we fix these two information holes, where UAAG was not followed, the Canvas 2d specification will not be suitable for the web. I'd like vendors to concentrate on the example that's already in the specification, instead of getting lost in the fray of wild ideas about composition and ATAG. ATAG is not what we're looking at right now. We're just trying to make the Canvas 2d spec pass WCAG. -Charles Other information: Content within the <canvas> element should receive focus when part of the tabindex order. It does not in the WebKit and Mozilla families. https://bugs.webkit.org/show_bug.cgi?id=50126 https://bugzilla.mozilla.org/show_bug.cgi?id=540456 This has been a known issue for years: https://www.w3.org/Bugs/Public/show_bug.cgi?id=8210 The focus issue is an implementation bug. It's a bug that Microsoft avoided in their initial support in Canvas. Microsoft uses a checklist for accessibility testing. That's very likely the reason why they caught the bug before shipping. Useful links about Accessibility: http://www.paciellogroup.com/blog/2010/09/accessibility-testing-tools-we-use/ http://en.wikipedia.org/wiki/Web_accessibility http://www.w3.org/WAI/WCAG20/quickref/ http://dev.opera.com/articles/view/26-accessibility-testing/#structuralinspectors
Received on Wednesday, 14 December 2011 23:22:45 UTC