- From: Charles Pritchard <chuck@jumis.com>
- Date: Sun, 18 Dec 2011 16:24:28 -0800
- To: public-html@w3.org, Canvas <public-canvas-api@w3.org>
- Message-ID: <4EEE843C.3040104@jumis.com>
"Should we add a caret location API to canvas, or is the focus API sufficient?" TL;DR: Please allow us to move beyond providing additional use cases. We've provided dozens. We can not answer this question when text accessibility has been declared an "invalid" use case. http://www.w3.org/html/wg/wiki/DiscussionGuidelines ... Canvas a11y will be blocked so long as the discussion revolves around the limited concept of "use cases". It is not possible to move forward on the "use case" model if the model does not allow for simple references to WCAG and empirical cases. We have not gained consensus that text navigation should be made accessible in Canvas. We have gained limited consensus that text blocks should be made accessible, though we are still unable to develop a conforming WCAG implementation of a simple checkbox. There has been a checkbox example in the Canvas 2d spec for a long time; WCAG has been available for review for a long time. This is a simple defect until its turned into an unending stream of use case rebuttals. Let me illustrate the case, very simply: Several real-world uses of Canvas were provided. They were essentially called invalid: "This would be better done in SVG." http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0184.html A developer took the more reasonable position: "while a lot of these are 'invalid' uses... I think we need to have a better accessibility story for them." http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html We seem to have lost that progress, with the developer making the following argument: "[developers] switched away from using canvas. The result was a more accessible user experience... the set of accessibility APIs that we have *now* deployed in canvas (i.e. basically none) lead the developers to create a more accessible editing experience" http://lists.w3.org/Archives/Public/public-canvas-api/2011OctDec/0085.html Sometimes performance comes up, as a reason why people use Canvas: http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0199.html http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0201.html The argument that having poor or zero-accessibility leads to a "more accessible" experience by discouraging authors from using Canvas is not productive. Yet it has been repeated by brilliant minds representing several vendors. This is not a productive atmosphere. It's rather wasteful. I've engaged in each one of these vendors as long as they've been willing to reply. Still, after so much time, we are in the same place. This issue is caught in deadlock. We can not establish consensus for an open discussion of caret location because real-world use cases are rebutted and technical citations to WCAG are ignored or neglected. As a Canvas author, I've explained that SVG and image maps are not a practical solution, though they are an attractive one. CSS overlays are not a practical solution, though they are an attractive one. contentEditable is not a practical solution, though it's an attractive one. I will certainly be posting these solutions to WCAG-TECHS for inclusion, as they are the only options for the current crop of browsers. But they are not going to get support from general Canvas developers. They are not integrated, they are inefficient, and they only benefit accessibility. If I thought there was a chance of them gaining widespread use, I'd push for them. Authors can not be expected to take heroic measures to make their applications accessible. They can't be expected to toss out their project and re-write it. They can't be expected to spend a quarter of their time writing inefficient code that outputs to two completely different rendering paths (eg. SVG + Canvas) simply to accomplish accessibility. Their applications already work. Authors are not going to abandon their code bases solely on the grounds that they do not meet WCAG. This is not an issue that Canvas authors are bringing up. This is an issue that accessibility people, following WCAG, are bringing up and developers with limited experience in authoring in Canvas are rebutting. I am weary and of the desperate determination that there are no ground rules left in the W3C beyond these: http://www.w3.org/html/wg/wiki/DiscussionGuidelines To vendors requesting use cases: please stop asking us to participate in circular discussions about the benefits of SVG over Canvas, and please stop suggesting that contentEditable will be sufficient in the future, or that a new specification should be written from scratch to "solve" a11y issues in Canvas. Those points have been made. My points have been made, and further repetition from me would be in violation of the discussion guidelines. Though I'm still willing to do so off-list. These are practical, measurable issues. With science. We can measure a11y; we can measure the time it takes to code in Canvas, the time it takes the browser to render, the disappearance of data. It's all measurable. This should not be stuck in philosophical debate when science exists to handle it. -Charles On 12/18/11 3:28 PM, Richard Schwerdtfeger wrote: > > I need the browser manufacturers to provide the tools to authors to > allow the author of this application to help a magnifier vendor assist > a low vision user in typing a text label for the drawing objects in > this application without providing the caret position. > > http://www.canvasdemos.com/2010/08/05/lucidchart/ > > Here is a real world use case. It is not a rich text editor. It is > simply entering a text label for a drawing object. A canvas author can > clearly use the canvas APIs to draw the text. All the browser > manufacturers can use this. Why won't you let a low vision user with a > magnifier do so? Maciej, Jonas, Ian, David Bolter, Ted please help me > out here. > > We posted this application use case months ago. > > Rich > > Inactive hide details for Charles Pritchard ---12/18/2011 01:07:41 > PM---On Dec 18, 2011, at 10:39 AM, Benjamin Hawkes-Lewis <bhCharles > Pritchard ---12/18/2011 01:07:41 PM---On Dec 18, 2011, at 10:39 AM, > Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote: > On Sun, D > > From: Charles Pritchard <chuck@jumis.com> > To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, > Cc: Steve Faulkner <faulkner.steve@gmail.com>, Jonas Sicking > <jonas@sicking.cc>, Sam Ruby <rubys@intertwingly.net>, david bolter > <david.bolter@gmail.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS, > Cynthia Shelly <cyns@microsoft.com>, "dbolter@mozilla.com" > <dbolter@mozilla.com>, "franko@microsoft.com" <franko@microsoft.com>, > Maciej Stachowiak <mjs@apple.com>, Paul Cotton > <Paul.Cotton@microsoft.com>, "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> > Date: 12/18/2011 01:07 PM > Subject: Re: Request to re-open issue 131 > > ------------------------------------------------------------------------ > > > > > On Dec 18, 2011, at 10:39 AM, Benjamin Hawkes-Lewis > <bhawkeslewis@googlemail.com> wrote: > > > On Sun, Dec 18, 2011 at 5:59 PM, Charles Pritchard <chuck@jumis.com> > wrote: > >> The HTML5 Editors draft uses scrollPathIntoView to accomplish the > same thing as setCaretSelectionRect but with a broader goal and > semantic. I've not been able to get its author to speak up on the > issue... They are both intended to fill in the caret tracking > interfaces present at the OS level. These are used by zoom apps, but > can also be used by heuristics in screen readers. > >> > >> The HTML5 editor did not use the caretBlinkRate semantic. > > > > Yes, likely influenced by implementor feedback. For example, Jonas > > Sicking has already indicated his opposition to Gecko implementing > > this: > > > > http://lists.w3.org/Archives/Public/public-html/2011Apr/0747.html > > > The two objections difficulty of implementation and fingerprinting are > put forward without proportionality. The blink rate getter for > platforms that have it is a trivial task. Jonas suggests otherwise. > How do we talk about a disagreement like that? I don't mean to rebut, > I want to have a constructive conversation. > > As for fingerprinting, it's true that a blink rate API may expose that > some users maybe running a popular AT screen reader. It's also the > case that users of screen readers may benefit from the functionality. > There are many many methods if fingerprinting, cache hit detection > amongst the best examples. They are tolerated and somewhat reasonable > when they exist as part of a purpose. The blink rate settings have a > purpose for the minority of users that have adjusted them. > > > > > >> If there are any ideas on how to salvage consensus on this > maxFlashRate concept, it'd be nice to hear them. This is different > than requestAnimationFrame use cases. This max flash rate is intended > for on-screen position and progress indicators to help authors stay on > the path to WCAG. > > > > Aryeh Gregor has suggested: > > > > "It seems like a small enough loss > > for canvas cursors to not respect user blink rate settings, but if > > it's not, could you work out some API that lets authors honor them > > without knowing them? I.e., let the author say "I want this to blink > > at the user's blink rate setting", without letting them know what it" > > > > http://lists.w3.org/Archives/Public/public-html/2011Apr/0770.html > > > > This is more complex to spec, but perhaps more likely to win acceptance. > > > I know I've had a difficult time with the "use case" system. I'm not > the author behind the blink rate proposal. I believe the primary > intent of the proposal is for WCAG first, then for AT screen reader > heuristics. > > http://www.w3.org/WAI/WCAG20/quickref/#seizure > > > I have no problem meeting that WCAG section without the API... Though > I'd not be picking up on the system settings put forward by screen > readers. Anyway... Afaik, Richard was fine with the blink rate > returning a static 500ms in browsers. > > This kind of opaque implementation is in line with Mozilla's stance on > pixel ratios with zoomed content. Something they only recently exposed > through CSS selectors. Mozilla treats the pixel ratio (think browser > zoom) as static in the JS environment whereas MS and WebKit do not. > It's a position they have taken and I'm at peace with the doing the > same here. > > I am not the right person to speak up for the blink rate proposal, but > I hope I was able to share some more information about it. > > -Charles >
Received on Monday, 19 December 2011 00:25:07 UTC