Re: Request to re-open issue 131

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