On Wed, Mar 2, 2011 at 6:52 AM, Charles Pritchard <ch...@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. >>> 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? -- Benjamin Hawkes-Lewis
