Re: html5 editor responds to Canvas accessibility related bugs

On 3 Oct 2010, at 19:30, Charles Pritchard wrote:
> On 10/3/2010 10:37 AM, Benjamin Hawkes-Lewis wrote:
>> Your other argument is that text editors should support "all" of the worlds languages. Nobody has that expectation.
>> [snip]
> This was made in the context of individual programmers serving their clients needs; it was not made in the context of browser-vendors distributing web browsers as part of their w3c obligations.

I've met plenty of web developers who insisted their clients' needs don't include supporting people with disabilities. That those needs might be met by "creative" use of web stack features is not (in my view) a justification for W3C to add further features tacitly endorsing such usage.

The same goes for internationalization.

> Real-world text is not constrained to the glyphs on a keyboard, nor the implementation status of the language within Windows, OS X, nor their content areas.

I get you're saying developers need to be able to build UIs in "canvas" to support some non-conventional input, and that's a worthy goal (and part of the accessibility and internationalization activities), but I'm not convinced (yet) that we need whole UIs built in "canvas" to support such input or that we should be trying to solve this problem on top of the web stack rather than /in/ the web stack. But I don't have a lot of familiarity with the IME problem space, so that may just reflect my ignorance.

Take pictographic input, which you mentioned earlier. Couldn't one use a "canvas" element for each pictogram? Or draw to vector (InkML/SVG) rather than a bitmap? Couldn't platform IMEs add support for such input?

Also, how would you represent a series of pictograms in a "canvas" to a browser so it could represent them to a platform accessibility API?

> I hear Oliver stating his concerns about programmers misguided attempts at language entry support, and how those attempts circumvent the work that he, and many others, put into their browsers. I don't feel that his stated recourse, of restricting individuals from working outside of the confines of browser vendor's language entry utilities, is an acceptable solution. I don't think we need a solution; that kind of management is best left to individual corporations.

But we're talking about asking browser developers to add features to support the creation of "canvas"-based UIs, when they could be devoting the same energy to improve the language support and accessibility of their whole platform. In the case of the company that introduced "canvas", this seems directly opposite to their approach to protecting the quality of end-user experience. Job's comments on why the iPhone does not allow apps built in Flash seem pertinent here:

http://www.apple.com/hotnews/thoughts-on-flash/

> As for SVG contentEditable, I think it'll be awhile, because it's been awhile. In the here-and-now, SVG support in browsers is improving, and will continue to. But, in the hear and now, I can do a lot more with "canvas"-based interactive graphics than I can do with SVG.

But to do so accessibly will require further spec and development work - work that could delay the delivery of SVG "contenteditable".

> I've been saying quite the opposite: that programmers should not be restricted by browser vendors, into how text editing may work in their web applications. That doesn't mean that we need to slow-down current APIs, make new half-assed APIs, or otherwise adjust resources.

I think the question is not whether browser vendors should "restrict" web developers, but what features browser vendors should prioritize to support end-users.

> Most accessibility proposals can more quickly and easily be prototyped in a canvas-based text editor than in a browser code base. I can hit reload faster in my web browser, using a JS prototype, faster than Oliver can compile WebCore and reload his browser.

The APIs involved in "canvas" accessibility will need to implemented in an application interacting with platform accessibility APIs to get a clear idea of their efficacy in terms of both accessibility and speed, so I'm not sure this is true.

> I'd hope that, instead of seeing our goals in conflict, we might move forward together, with our varying strengths, motivations and resources.

I think the disagreements here reflect differing strategies, not differing ultimate goals.

--
Benjamin Hawkes-Lewis

Received on Sunday, 3 October 2010 21:23:31 UTC