- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 02 Mar 2011 08:59:17 -0800
On 3/2/2011 12:07 AM, Benjamin Hawkes-Lewis wrote: > On Wed, Mar 2, 2011 at 6:52 AM, Charles Pritchard<chuck at jumis.com> wrote: >> My understanding is that those items are covered by DOM, and WebIDL, which >> HTML inherits from. >> There's a bulk of APIs under the "webapps" group, covering much of the rest. >> >> I think that HTML spec is primarily a format spec, not an API spec. > Do you mean you think it /should/ be? The current draft specification > is clearly a vocabulary plus APIs spec. Sorry about my poor quality response. You're correct, it's more than a format, and does include some APIs; and abstracts a few UI widgets. >>>> Unfortunately, contenteditable is less accessible to users than it >>>> should be. I'd like to see that addressed. >>> Could you elaborate on how it is less accessible than it should be? >> I can't. But I can give some examples of shortcomings, as the Google word >> processor >> and Microsoft's editor are both quite short of coming anything near desktop >> word processing. >> >> The CK editor is certainly still a great example of pushing it as far as >> they can. > These aren't examples of accessibility shortcomings in the spec or > examples of accessibility shortcomings in products but just examples > of products you think have accessibility shortcomings. > > Can you give concrete examples? > >> My understanding is that rich text editing is really handed off to the UA >> (reading that from the ARIA >> spec under the Rich Text editor control), and that it's usability is a UA >> issue, not a scripting/format issue. > Are you saying there's nothing the HTML spec can do to improve matters? > > If UAs applied UUAG2 to their implementations of contenteditable, would that > address the problems to which you allude? Or is UAAG2 missing some important > advice? I'll work on it in the future. -Charles
Received on Wednesday, 2 March 2011 08:59:17 UTC