Re: html5 editor responds to Canvas accessibility related bugs

  On 10/3/2010 1:55 PM, Benjamin Hawkes-Lewis wrote:
> 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.
You're getting your perspective from the wrong crowd.

We're talking about supporting people with disabilities:
focus on the web developers whose needs include supporting people with 
disabilities.

Those people may need creative solutions to the web stack, to support 
their users. Disabilities require "creative" solutions. They're not 
better or worse, just different.

Again, I'm a fan of the web stack. Part of my iteration process, every 
once in awhile, is to boot up elinks/lynx and see what happens. Thank 
you everyone for the <canvas> shadow dom.

>> 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'd use event.dataTransfer and other clipboard-related apis, I'd try to 
check the width/height of the screen
as well as the current scale of pixel. Beyond that, I can't do much.

If there were APIs, I'd report where the current selection and/or caret 
is, I'd check if there are additional settings on the browser, such as 
high-contrast,
color blindness (of varying degrees), large-font, etc, and add some 
handling for those cases.

We're talking about very basic structures in the browser; these aren't 
technical problems, they're not costly to support,
and none of those are necessarily intrinsic to canvas developers.

However, the push-back on the issue, of text editing in canvas has 
halted better thinking in area of accessibility APIs.
> 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/
It's not. Job's early comments on the idea that iPhone apps could be 
developed entirely in Mobile Safari are pertinent here.
Most iPhone apps use a 2d or 3d surface API.

>> 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".
Or support the delivery of that same element. Canvas based 
implementations of SVG are the best and quickest place to test the 
feasibility and cost of new ideas.
Canvas is not mutually exclusive of any W3C spec.
>> 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.
I certainly agree with that. But that's not the reasoning that Ian and 
Oliver are putting forward here. I'm disappointed, as Ian usually 
focuses on priorities, not on disparaging programmers efforts.
>> 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 can handle color blindness in JS, zoomable interfaces, caret position 
and selection, without touching a compiler. I don't need these APIs to 
be implemented in order to use them. They just provide me with some 
standard names and arguments to use when I program.
>> 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.
My ultimate goal in this discussion is to unblock the issue of "canvas" 
being used in text editing.
Richards goal is to expose additional accessibility APIs to programmers.

Oliver and Ian are intent on repelling APIs which tacitly acknowledge 
the existence of canvas-based text editors.
Otherwise, I think they're right there with Richard on their goals of 
greater accessibility and flexibility of content.

As I see it, my goal is different. I've been told that implementing HTML 
Forms in canvas, dom and css, is a waste of time.
It seems to be in direct conflict with Ian's intent of protecting 
developers from ... text editing.


-Charles

Received on Sunday, 3 October 2010 22:01:54 UTC