- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 16 Jan 2011 22:02:09 +0000
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, Frank Olivier <Frank.Olivier@microsoft.com>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, "janina@rednote.net" <janina@rednote.net>, "oedipus@hicom.net" <oedipus@hicom.net>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, Shawn Warren <swarren@aisquared.com>, Tim Lalor <tlalor@aisquared.com>
On Sun, Jan 16, 2011 at 5:34 PM, Charles Pritchard <chuck@jumis.com> wrote: > On 1/16/2011 8:35 AM, Benjamin Hawkes-Lewis wrote: >> >> The idea is that people use canvas to build RTEs to solve a series of >> problems that are not canvas-specific and that there is a severe >> opportunity cost to helping people solve those problems with canvas >> rather than @contenteditable. This goes for multiple aspects of building >> an effective RTE, including not only accessibility but also security, >> internationalization, and integration with system services. > > Fine with that: provided the opportunity cost is actually analyzed. Sure. > As you know, I'm a big fan of serialization. > > Currently, contentEditable is something of a black box, with a few features > thrown in, borrowed from Microsoft's early work on the feature. "black box" in what sense? http://en.wikipedia.org/wiki/Black_box > As for canvas-specific: there are a few details that should be addressed, > and they are, via drawFocusRing, blink rate and the caret selection command. > > Beyond that, I think the defects are in contenteditable, existing html form > elements, and some parts of viewport handling. >> >> We're dealing here with at least four broad use cases: >> >> 1. Collaborative coding in an integrated development environment in >> the cloud (Bespin). >> 2. Enabling users to enter rich text in multiple languages (Google >> IME). >> 3. Using a cross-platform widget set to write an application once and >> deploy it in multiple environments (GTK client). >> 4. Providing access to a remote desktop environment (VNC client). > > Yes, some of the use cases are a little artificial, as my original intent > was more technical: I don't understand the distinction you're making, but I think we should discount "artificial" use cases and focus on real ones like the above. > I'd like methods for serializing the UI-state of an RTE, per WCAG, What WCAG requirement are you talking about? WCAG2 does not mention serialization. > so that, it may be restored, As I've said before, you don't need new features to support this. > and so that it may interface with AT. I think there's general agreement that web RTEs should be accessible. > I'd like the RTE to work to the standard that users expect. Which standard is that? > 1. This started from technical use cases: serialization, unit testing. Re unit testing: I cannot find the previous discussion of unit testing in this context. Would you mind linking to it? Has anyone analyzed what sort of things need to be unit tested, what unit testing cannot be done at the moment, and whether the proposed features are sufficient to enable it? Have any alternative approaches or features been considered? Re serialization: use cases are about user needs. "Serialization" is a feature but it's not a use case. I could say I need to serialize the names of my cats, but that's not a use case. http://en.wikipedia.org/wiki/Serialization http://en.wikipedia.org/wiki/Use_case If by "technical use case", you mean a "use case" that is not directly tied back to meeting end-user requirements, I think we should discount such "use cases" in order to make sure we're solving real user problems. > The "cloud" IDE is just something to point to. Are you saying we should ignore this use case? If so, I disagree. Unlike serialization, it's a real case based on user requirements that user agents might be interested in supporting, and we should consider whether we can support it and how. And if the use case is brought forward - however tenuously - as a rationale for introducing specific features, we should certainly analyze whether those features address the use case well or not. > I really think the basics should have been sufficient. If the "basics" were collectively recognized as sufficient, then people would not be "pointing" to additional use cases. > 2. Enabling authors to develop rich text alternatives. Yes, it may be > for transliteration, it could be for handwriting recognition -- it > could be for an artificial language, or it could be a UI for an AT > solution. It could also be for design: think Adobe Illustrator, where > the user can edit text in place. These all sound like use cases, although obviously we'd need to elaborate them in detail to work out what features would support them best and how much urgency to assign to them. Transliteration: Not sure what you mean or how the proposed features help. Handwriting recognition: I don't understand why we need the proposed features for handwriting recognition. Artificial languages: I can't see implementors treating this as a strong motivation for adding new features. I think the web stack already supports outputting these using a series of SVG, canvas, or img elements. UI for an AT solution: Not sure what you mean or how the proposed features help. Vector graphics editing: Given that Adobe Illustrator can output SVG, it seems like SVG is already a great fit for this, so I don't see why we need the new features to support this. > I've brought up legibility, to Mozilla, and been denied. > I've brought up text alignment (putting two fonts on the same baseline), and > been denied. Hammer vendors have their own ideas about the purposes of hammers, which don't include turning them into spanners. > It's a miracle that the Shadow DOM ( drawFocusRing ) was allowed > through. That said, WebKit is still lagging on allowing focus to > elements in the shadow DOM. Chromium developers are having broad > issues with JAWS, with "non-focusable" elements. I haven't heard about these difficulties. Do you have any links to further information? >> The reasons given for creating an IME in canvas are all /stronger/ >> reasons for implementing good IMEs directly in the browser: >> >> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029759.html > > There's a basic fallacy in that sentiment: that all IMEs should be written > directly in the browser. My sentiment does not depend on such a strong claim. I'm saying the reasons mentioned are all better reasons to improve browser (and system) IMEs than to require browser developers to add features for authors to roll their own. > One of the purposes of the scripting environment is to allow authors to > develop alternatives. It's a way authors use the environment, but it's inefficient to require the diversion of development resources that would be better spent elsewhere. > I've said it many many times -- language is not static, and programming is a > form of expression. > > Restricting IME to that which is supplied ONLY by browser vendors goes > against free speech. Authors and browser vendors are not different types of people, they are just people (not that infrequently the same people) playing different roles. *You* are proposing new restrictions on people's form of expression - that software written by other people must include X, Y, and Z features to be conforming with a web standard. Of course, this is a fairly weak restriction, as generally developers won't implement requirements they feel are unreasonable. (For example, developers generally don't go out of their way to use complex bolt-on accessibility features.) Just because some hammer vendors won't make you a hammer that also works as a spanner, doesn't mean you have the right to demand a hammer-spanner from them or deny you the freedom to make your own hammer that does. If you're not interested in writing the software to solve the problem of enabling developers to code an RTE in canvas, that does not (in my view) give you some sort of special ethical right to demand that other software writers solve it for you. We are talking about what constraints we can reasonably place upon conforming HTML5/ARIA implementations. We cannot ultimately constrain what developers do on the open web, so "Restricting IME to that which is supplied ONLY by browser vendors goes against free speech" is a strawman. >> I think canvas does have a potential role to play in addressing the >> remote desktop environment use case, but I don't think the proposed >> features help. I'll discuss that use case in a new thread. > > Yes, current remote desktop environments use pixels. > > There are some basic implementations of Flash using Canvas: they provide > something of a demonstration of using an API, instead of pixels, for > display. Today's desktop environments do not draw using Flash, so I don't see the relevance. > It's certainly possible to hook into higher level API functions, and send > those function calls over the wire, and implement them in Canvas. That requires that desktop environments and their applications be reimplemented to restrict themselves to higher level API functions that could be sent over the wire. I think it's more likely that in twenty years: 1) The remote desktop environment access use case will be obsoleted by ubiquituous cloud computing. *or* 2) People will still require remote access to desktop environments where applications still take advantage of platform-specific low-level APIs. If I'm wrong, then adding some extra API to HTML5 canvas to support remote access will be the most inconsequential part of the puzzle that needs solving to get us from where we are to where you think we could be. Rewriting the desktop application stack and devising protocols for transmitting instructions over the wire to express those applications remotely even on different platforms would be the hard parts. >> The web standards community did advise against *depending* on JS; that >> was good advice at the time and remains good advice today. There are use >> cases where it's impractical advice; text entry isn't one of them but >> real-time gaming, instant messaging, and remote desktop access are. > > WebApps have a very different use case than hypertext. I suspect we're going to keep disagreeing on that point. :) > It's not reasonable to expect all app developers to have a fully > accessible non-graphical UI to their application. Requiring or not requiring JS and providing or not providing a fully accessible non-graphical UI are strictly orthogonal concerns. Non-graphical UIs may require JS; graphical-only UIs may not require JS. If you mean there are some applications for which it is impossible to create a fully accessible non-graphical UI, then I've yet to see an application of which this is true, but I can believe they might exist. I think where the technology exists to create multiple representations of the same application flow from the same blueprint, it's not an unreasonable user expectation. I favour expanding the parts of the web stack that support that ability. That's not the same as saying that users have an ethical right to *demand* such alternate representations. >> So long as we're looking at history, though, Flash provides a good case >> study of why built-in accessibility (@contenteditable) is preferable to >> bolt-on accessibility (canvas RTEs): authors don't use bolt-on > > This isn't an either-or situation. > > It makes a lot of sense to use HTML specs in Canvas RTEs. > Richard's Checkbox example uses actual checkbox elements. > > Canvas based HTML Forms use HTML elements, per the specs. > > This is [if I'm not going to far], the right way to do a canvas RTE: > <canvas><div contentEditable>Editable Content</div></canvas> If there's a right way to do it, that's probably it, but it still requires bolt-on accessibility so it's still subject to the historical lesson of Flash. > The issue at hand, is that it can not be discussed, without being > chilled by authority figures who have no experience nor stake in the > matter. I think "chilled" is the wrong word to use for a situation where hammer vendors are not keen on making the spanner you want. > Opportunity costs are not being weighed. > > Proposals which cost very little are not rationally analyzed as their use > case is labeled "Canvas RTE". I disagree that the proposals "cost very little" and "are not being rationally analyzed". Which is not to say that the analysis cannot be improved. > When a browser vendor like Mozilla outright states that things have > been obfuscated, intentionally, it means there's Zero room for sending > in patches to fix the issue, I don't think the statements of individual Mozilla developers mean there is zero room for sending in patches. Anyway, Gecko's a FOSS code base. Disagree with a decision from on high? Fork it. >> It's been a struggle to get AT vendors who are not *also* browser >> vendors (Apple, Opera, Microsoft) involved in the standards process, >> so I'd like to complement you on getting AI Squared involved. It's >> really good news. :) > > Bad style to complain... but still... Apple has been absurd in this > area. They control their stack, from top to bottom. Minding positive iPhone and Mac experiences enjoyed by blind acquaintances, I disagree that's a bad thing. http://blog.fawny.org/2010/11/25/badtastehasacost/ http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/ Please note: As a long-term user of *both* stacks, I also value the ultimate freedom to DIY offered by FOSS stacks like Linux-Gnome-Orca. I'm glad we have an ecosystem capable of supporting both types of stack, and people working on accessibility in both stacks. > Whenever AT is brought up, the answer is, "we already have it in our OS". Sounds good to me. :) But it's worth noting that actually Apple isn't the only company working on AT on their platforms. http://www.assistiveware.com/ http://www.macspeech.com/ > With other vendors, the standard vendor reply is, "well that's something > that should be handled automatically by the UA, not by the author." Indeed. Hammer vendors like making hammers that hit nails, rather than hammers that require you to get the nail vendor to make their own special attachment for your hammer in order to hammer in their brand of nails. > I've been told, repeatedly, that authors don't know what they're doing, so > vendors can't expose additional APIs. Even at the cost of a11y. If authors are totally sacrificing accessibility in order to use canvas, sounds like good evidence that they either don't know what they're doing, or don't care enough to take advantage of bolt-on accessibility features and that if their work ever achieved web-scale importance, it would require a flock of accessibility experts to come and redo their work so that it's no longer broken. Ahem… http://groups.google.com/group/jquery-a11y http://www-03.ibm.com/able/resources/dojo.html Built-in accessibility means that ignorant authors can still produce accessible content and functionality, that knowledgable authors don't end up trading in accessibility to cut development time, and that you don't need to retrofit accessibility after corners are cut. There are use cases where built-in accessibility seems very difficult to achieve, such as providing audio descriptions or captions for media. I don't think RTE is one of those use cases. > Microsoft is generally silent, though I appreciate their growing public > attendance. I agree the growing involvement of Microsoft in web standards is a good thing. :) -- Benjamin Hawkes-Lewis
Received on Sunday, 16 January 2011 22:06:18 UTC