Re: html5 editor responds to Canvas accessibility related bugs

On 9/28/10 10:32 AM, Oliver Hunt wrote:
> Anyone attempting to use canvas as a mechanism to implement a text 
> editor (I am unsure why people insist on wanting to do this) has more 
> problems than simply accessibility.  You also have to worry about the 
> text input managers that people use, and that's something that cannot 
> be reasonably standardised.
Key codes are reasonably standardized. That's as much as is needed for 
experimentation and audience specific development.
> To get correct behaviour an application needs to implement a huge 
> amount of functionality so that all languages are covered.  I have yet 
> to see _any_ attempt to create a text editor that gets this right, 
> even those attempting to simply position their own logic between the 
> use input and the browser's own editing machinery.
This is certainly an issue for browser vendors releasing world-wide.

But it's not an issue for developers targeting a specific audience.
Remember, we're talking about an API for those developers.

A developer may only need to support one script, one language, or 
perhaps, a minority language.
They may be supporting glyphs, for an accessibility project for various 
reasons.

While I greatly appreciate your attention to supporting "all languages" 
as a browser vendor;
restricting end users to only using the scripts and languages that 
you've supported, does not
further your goals, nor your end users.

Think of pictographic input -- it may still be helpful to have a cursor, 
focus events, etc.
Think of minority scripts, and "non-standard" writing. Think of leaving 
room for people
to explore accessibility, to work with creative uses of displaying text 
entry.

Mostly; remember that the map is not the territory, and "standard 
language practices"
are not "language". This is an area I feel passionate about, as I see 
good intentions
conflicting with the liberal attitude commonly held by anthropologists 
in sociolinguistics.

> I think that rather than trying to hack accessibility onto a feature 
> so that it may be used for something it was never intended to do, you 
> should detail the missing functionality that you want/need from the 
> normal text editing machinery that lead you to attempt to write your 
> own editor in a canvas.

I am not speaking to the merits of Richard's current accessibility 
proposals. I've come into the conversation because I'm concerned about 
the process.
Reiterating my primary point: it's perfectly reasonable for vendors to 
pursue standard language practices, but restricting the specification
because somebody may use language "the wrong way", is a worrying direction.

I'd be happy to solicit comments from people within the field of 
linguistic anthropology, to bring some additional context into the 
discussion.

That said, I'm firmly rooted in my position that editing text/glyphs, is 
not something that should be intentionally restricted.

Apart from that... It seems that many here have lost sight of the 
growing "Web Apps" audience. I perfectly understand instructing content 
authors to use proper markup and CSS. HTML 5 is actively being used as 
an application development platform. It's an entirely different audience 
of users and authors.

-Charles

Received on Tuesday, 28 September 2010 21:10:16 UTC