Re: Working Group Decision on ISSUE-205: caret-location-api - and Issue 131

Which of these objections were stated in response to the survey?

Do intend to collect and pesent new information?

- Sam Ruby

On 08/02/2012 12:59 PM, Richard Schwerdtfeger wrote:
> Rich Schwerdtfeger
> Maciej Stachowiak <> wrote on 07/17/2012 08:56:10 PM:
>  > From: Maciej Stachowiak <>
>  > To: " WG" <>,
>  > Date: 07/17/2012 08:58 PM
>  > Subject: Working Group Decision on ISSUE-205: caret-location-api
>  >
>  >
>  > The decision follows.  The chairs made an effort to explicitly address
>  > all arguments presented in the Change Proposals on this topic as
> there were no
>  > additional responses in the poll itself.
>  >
>  > *** Question before the Working Group ***
>  >
>  > There is a basic disagreement in the group on whether additional
>  > accessibility functionality for canvas text editing, tracked as ISSUE
>  > 205. We have two distinct proposals for this question, and a straw poll
>  > for objections.
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > == Uncontested parts of the proposals:
>  >
>  > The following points were made and not disputed, and in some cases
>  > explicitly stipulated by both proposals:
>  >
>  > - There exist some applications which do in-canvas text editing
>  >   (specific examples: Ludicart Drawing Tool, LibreOffice Online)
>  > - In-canvas text editing is lacking in accessibility.
>  > - Combining text editing with canvas is a valid use case (though how
>  >   best to do it is disputed).
>  > - The "CaretSelectionRevised" proposal provides sufficient
>  >   functionality to support accessibility of in-canvas text editing.
>  > - Superimposing text fields on top of the canvas is an existing
>  >   alternative approach to meeting these use cases (though it is
>  >   disputed whether it is complete, or the best approach).
> A key reason for the CaretSelectionRevised proposal is to allow for
> magnifier tracking in during content selection. A superimposed text
> "field" does not allow for selection of rich text content that could
> span paragraphs of information with embedded content.
>  > - Superimposing text fields is sufficient for simple use cases, though
>  >   whether it is sufficient for more advanced use cases is disputed.
>  > - In-canvas text editing has many weaknesses and limitations,
>  >   requiring significant reimplementation and making it challenging
>  >   (perhaps in somc cases impossible), to deliver some
>  >   non-accessibility editing capabilities.
>  >
>  > They are assumed valid in the analysis below.
>  >
>  >
>  > == Use cases for in-canvas text editing:
>  >
>  > It is not disputed that canvas-based applications which also do text
>  > editing are a valid use case and are actually used in the wild. It is
>  > also accepted that such applications must be made accessible. This
>  > would form a strong objection to any proposal that does not address
>  > these use cases. This is not disputed for the "CaretSelectionRevised"
>  > proposal, but it is disputed for the
>  > "No_edit_change_proposal_for_canvas_text_editing" proposal. So we must
>  > examine the latter proposal in more detail to fully evaluate this
>  > objection.
>  >
>  >
>  > == Superimposing text fields as an alternative:
>  >
>  > Superimposing text fields over a canvas is conceded to be sufficient
>  > for simple use cases, such as editing a label on a graph.
>  >
>  > However, one proposal argued that superimposing text fields is
>  > insufficient for rich text editors using "embedded font layout, custom
>  > fonts, and arbitrary objects and glyphs". No supporting evidence was
>  > given for this claim. The other proposal says that superimposing a rich
>  > text editing control is sufficient for more complex use
>  > cases. Microsoft Office online and SkyDrive were cited as examples
>  > using this technique.
>  >
> A text field is limited to text. For things like entering simple text
> labels this is adequate. However, if one were to select content across
> rich text this would include: embedded tables (which have context
> information associated such as headers), bitmaps, drawings, etc.. Those
> items, by definition, do not equate to text and during content selection
> the additional semantics cannot be conveyed to a blind user as they
> don't exist in the text field. It is for this same reason that
> applications like MS Word (desktop) would not overlay a text field so
> large that it would cover the entire document for sighted users creating
> an accessibility issue, that did not exist, for sighted users.
> Nowhere in the other proposal
> (
> does it state that overlaying a text editing control over the existing
> control allows someone who is blind to be able to select content. There
> is no statement anywhere in this proposal that states that the
> technology works fully with today's screen readers like JAWS. One cannot
> make the assumption that just because it was implemented with a text
> field that the solution itself is robust enough to support a screen
> reader. Having actually been part of a team that has built a screen
> reader and having spoken with a major AT vendors they agree that the
> floating text field solution does indeed have problems in conveying the
> user's context within the document. Once you leave the text field text
> selection tracking fails
> Although I don't have access to the online version of Microsoft Office I
> do have access to the desktop LibreOffice. LibreOffice superimposes
> individual text fields within groups over the content and the text can
> be read. The problem we are trying to solve is text selection tracking
> for magnifiers and screen readers. Nowhere does it state in this
> proposal that you can can select text across multiple text fields and
> convey to the screen reader user or blind user the context as to where
> they are in the document as within the text field the information does
> not exist. I ran selection of text across LibreOffice and it did in fact
> fail to allow either a magnifier or a screen reader to track the
> location of the selection point across text fields. VoiceOver on MacOSX
> 10.7.4 was able to read the text within the text fields but text
> selection failed completely and it failed to track the selection across
> multiple lines of text and embedded graphics. I do not believe this is a
> failing in VoiceOver. In LibreOffice each textfield was limited to a
> range of text and VoicOver actually draws a bounding box around that
> field illustrating that when you go and select many lines of text and
> embedded drawing objects you lose the context of what you are selecting.
> In the future I would ask that when the chairs read a proposal they also
> ask whether the solution fully works with assistive technology as this
> is the problem we are trying solve. Simply saying that a solution
> "works" with Microsoft Word and Skydrive does not mean it works for
> people with disabilities.
>  > On the whole, it seems like overlaying a text field or a rich text
>  > control is a viable alternative; no evidence is provided otherwise. In
>  > fact, a specific example is provided of the rich text case. Thus, the
>  > objection to the overlay solution is taken to be a very weak objection
>  > for lack of evidence.
>  >
>  >
>  > == New vs existing features:
>  >
>  > We conclude that both proposals meet the required use cases. Normally
>  > the presumption is against adding new features when existing features
>  > would satisfy the use cases in question. The new feature would have to
>  > show compelling benefits that make it far better for at least some
>  > uses, and which are not offset by the disadvantages.
>  >
> The conclusion was based on not trying the approach with an assistive
> technology and seeing the problems which I do hope the chairs are now
> able to see.
>  >
>  > == Argument from existing use of canvas-based editing:
>  >
>  > One survey objection states, with regard to the
>  > "No_edit_change_proposal_for_canvas_text_editing" proposal:
>  >
>  >     As already noted, this stricture has not worked. There's no
>  >     evidence this will change. We have not heard that LibreOffice will
>  >     withdraw, nor have we any evidence that some author will not ask
>  >     something as simple as "Enter your name here:" in canvas.  So, if
>  >     the WG cannot prevent text editing in canvas, it should recognize
>  >     that a11y will be harmed if the technology to support assistive
>  >     technologies is excluded. Please do not undermine a11y over an
>  >     unwinnable preference.
>  >
>  > Considering this statement generally, it doesn't seem to be the case
>  > that *no* canvas-based editor will change its approach. This seems to
>  > be false as a universal claim. Mozilla Bespin (later Skywriter and
>  > then Ace) was a frequently cited canvas-based text editor which has
>  > moved to non-canvas-based editing.
>  >
>  > To interpret this argument in the strongest possible way, let us take
>  > it as a claim specifically with regards to LibreOffice Online, a
>  > product that has been cited directly. No technical reason is provided
>  > for why LibreOffice Online could not use existing HTML features to
>  > achieve accessibility. No technical obstacles are cited.
>  >
> The issue is not whether LibreOffice could create an RTE with HTML. It
> is the fact that they chose canvas to do it. Google Docs did not use
> contenteditable either. I did ask Dominic Mazzoni as to why the Google
> Docs team chose to not use canvas. He sighted one example as the concept
> of pages not being in contenteditable. Also, a quick look of the YouTube
> video of LibreOffice online shows inline drawing functionality in the
> presentation whose functionality does not reside in contenteditable.
> That said, you have:
> Microsoft 365
> LibreOffice
> Google Docs
> and none of them has implemented contenteditable. It should be up to the
> chairs of the HTML working group to ask them those questions and not
> place the burden on the people who are working to make a technology
> accessible. This is comparable to the chairs saying why use Microsoft
> Word on the Mac, which is not accessible, and use the Apple office suite
> solution because it is. It has absolutely nothing to do with a technical
> solution. If a company were to deploy LibreOffice to their employees
> today they would not be able to use it. The answer is NOT to tell the
> LibreOffice people to write LibreOffice as a contenteditable document.
> What's more <canvas> IS an HTML feature. Unless the HTML working group
> wishes to remove it then we should address its accessibility.
>  > This is on some level a valid objection. However, LibreOffice Online
>  > is not a released product; it exists (as far as can be determined)
>  > only as a prototype, and can be seen only in the form of a demo
>  > video. As seen in the cited email announcement, this product was
>  > created with the knowledge that canvas text editing was controversial,
>  > and that accessibility functionality was missing. Given this, the
>  > argument based on inconvenience of change can only be given limited
>  > (moderate) weight.
>  >
> LibreOffice online is at version 3.5 online. It is not clear that it is
> at product level. I do not know if the LibreOffice team was aware of
> this accessibility deficiency but I do believe, as a product, that they
> are in the early stages - releases aside. It is undisputed that
> LibreOffice has not addressed accessibility for their online version
> which currently only works on Windows. I tried it on Windows and it did
> not work with the screen reader I tried.
> Canvas accessibility functionality is missing as at the time they began
> work on LibreOffice we had not yet made a lot of progress on canvas
> accessibility and in fact one could also argue that HTML5 is not done,
> accessibility aside.
>  >
>  > == Non-accessibility Limitations of direct in-canvas text editing:
>  >
>  > As noted above, in-canvas text editing has many weaknesses and
>  > limitations, requiring significant implementation work to provide
>  > various non-accessibility features. Examples include international
>  > text input (IMEs) and system spellchecking.
>  >
> While this is true, the chairs should not be ignoring an accessibility
> issue simply because something is hard to do today. I am quite sure that
> when Microsoft Word went from a text based interface to a GUI that it
> was not a trivial task. In fact, a new W3C API is being developed to
> facilitate the development of IMEs and it can be found here:
> I would also argue that early releases of the Windows GUI was not a lot
> different from canvas today in that canvas provides a 2D drawing API and
> as we add features like hit testing it will have even more of the needed
> functionality required to produce a rich GUI experience.
>  > The caret/selection API would not address these, as the warning text
>  > and the alternative technique of overlaying a text field or rich text
>  > control does.
>  >
> It is not intended to address internationalization. Overlaying a text
> field does not in fact address rich what the additional caret/selection
> tracking API does as highlighted earlier and the chairs have given no
> evidence that they have tested content selection with an assistive
> technology across large amounts of rich text with embedded content. Also
> the chairs have not discussed with whether a floating text field
> interface would provide a rich usable experience on par with what a user
> experiences with say a native Microsoft Office application. Having
> actually built a screen reader and discussed this issue with a major AT
> vendor the conclusion is that it does not.
> Rather, the chairs simply stated that two applications employed text
> fields for text entry. Here is the the actual text from the "do nothing"
> proposal:
> "For cases where more rich editing is required, other solutions already
> exist: Online versions of Microsoft Office and SkyDrive already
> implement a rich text editor by overlaying an editing control on top of
> the main document."
>  > One survey objection counters this, saying "Yet, LibreOffice has
>  > already built a rich text editor in canvas that supports multiple
>  > languages." This statement is vague as written. It's not clear if this
>  > means that LibreOffice supports all or most of the challenging text
>  > editing features, a subset including all the features related to
>  > internationalization (including IMEs), or merely some form of
>  > multi-language support.
>  >
>  > The interpretation as "some form of multi-language support" would not
>  > rebut the argument that canvas-based text editing is deficient in
>  > crucial ways. It is too limited a claim. Therefore let us examine the
>  > stronger forms.
>  >
>  > If the claim is that LibreOffice Online supports all
>  > internationalization-related text editing features, including support
>  > for system-built in international text input methods, then this is an
>  > extraordinary claim. Such an extraordinary claim would require
>  > extraordinary evidence. Because LibreOffice Online is only a prototype
>  > and not yet (apparently) available online, it is impossible to check
>  > the claim directly. A vague claim that LibreOffice Online "supports
>  > multiple languages" is not sufficient evidence for this type of claim,
>  > if that is indeed the claim being made.
>  >
> This is a gross overstatement of what was stated in the survey poll. The
> actual text reads: "Yet, LibreOffice has already built a rich text
> editor in canvas that supports multiple languages."
> In no way does that say ALL languages. What is not disputed is that the
> online version is a prototype.
>  > Overall, then, the severe limitations of canvas text editing form a
>  > moderately strong objection to the CaretSelectionRevised
>  > proposal. Since (apparently) the use cases for accessible editing in
>  > canvas-based apps can be otherwise met with the overlay technique, the
>  > fact that the direct in-canvas technique would omit key functionality
>  > is an important point to consider.
>  >
>  >
>  > == Arguments that were given no weight:
>  >
>  > - "I object to having this text in the HTML5 spec. as it states that
>  >   authors should not do rich text editing using canvas because it is
>  >   technically hard..." -- Neither proposal suggests removing the
>  >   warning text in the HTML5 spec. Thus, this argues for a proposal
>  >   that is not on the table.
>  >
>  > - "..the company advocating this change proposal is the largest
>  >   producer of rich text editing products brings into question, for me,
>  >   the motivation for making this change proposal." -- Ad hominem.
>  >
>  > - "If it were not technically feasible to produce a rich text editor
>  >   in canvas or it were proven that we could not produce an accessible
>  >   rich text editor with canvas then those arguments would be grounds
>  >   for having this text in the document..." -- No one made either of
>  >   the claims rebutted here.
>  >
>  >
>  > *** Decision of the Working Group ***
>  >
>  > Therefore, the HTML Working Group hereby adopts the <data> element change
>  > proposal:
>  >
>  >
>  >
>  > Of the Change Proposals before us, this one has drawn the weaker
> objections.
>  >
> I did my best to address the claims by the chairs above. It is clear
> that proposal that essentially says "do nothing to support rich text
> editing" did not prove that a floating text field would provide for rich
> text *accessibility*.
> There was no evidence that the author spoke to assistive technology
> vendors nor that they have the assistive technology background to make
> the claim that this is a good solution to the problem. His claim was
> simply that to products employed a floating text field. I have looked at
> an implementation of this strategy and I have determined it to be
> inadequate and I have discussed it with a major Windows screen reader
> vendor and they also found the approach to give a poor user experience
> to a blind user. It is also clear that the chairs read the "do nothing"
> proposal and made the extraordinary assertion that that a floating
> textfield provided an usable accessibility experience which it cannot as
> text field cannot provide rich semantics provided for in the document
> itself nor can it allow for caret tracking across broad selections of
> text including those that reside inside table cells. Products like the
> desktop version of Word and Symphony provide direct access to the their
> DOM and allow the caret to be aligned with actual content in the
> document as well as their semantics. A floating text field does not NOT
> that. This proposal does:
> as
> it is designed to work with the fallback content and the actual location
> of the caret and selection location on the physical canvas.
> What I do not dispute is:
> - rich text editing in canvas is in its early stages.
> - IME is temporarily difficult but new APIs are being created to address
> this on the web to make it easier
> - The LibreOffice team did not address accessibility in their online
> version, nor did they approach anyone from the HTML5 working group for
> help. I personally emailed Michael Meeks (LibreOffice) to discuss this
> and did not get a response. The reasons were not clear.
> - For simple text entry, such as entering a label, a floating textfield
> will suffice
> */For these reasons I would ask that the chairs move issue 131 to
> and save proposal
> /**/ for
> review at that time. This will give more time for canvas,
> contenteditable, web-based IME support, and cross-cutting accessibility
> support to develop and mature. If the chairs agree to then I would
> support the chairs decision for HTML5 as a temporary one requiring
> greater view in the next version, otherwise I will need to formally
> object to the chairs decision. /*
>  >
>  > == Next Steps ==
>  >
>  > Since the prevailing Change Proposal does not call for a spec change,
>  > no further action is required. ISSUE 205 will now be closed.
>  >
>  >
>  > == Appealing this Decision ==
>  >
>  > If anyone strongly disagrees with the content of the decision and would
>  > like to raise a Formal Objection, they may do so at this time. Formal
>  > Objections are reviewed by the Director in consultation with the Team.
>  > Ordinarily, Formal Objections are only reviewed as part of a transition
>  > request.
>  >
>  >
>  > == Revisiting this Issue ==
>  >
>  > This issue can be reopened if new information come up. Examples of
>  > possible relevant new information include:
>  >
>  > * Identification of one or more actual tools (more is better) with
>  >   requirements that can't reasonably (as determined by the authors of
>  >   these tools) by satisfied by the existing HTML Canvas functionality,
>  >   potentially augmented by techniques such as superimposing text
>  >   fields; explicit identification of these requirements and
>  >   limitations; identification of features which specifically address
>  >   these limitations; and an indication by the authors of the tools
>  >   cited that they would actually use these features if they were
>  >   provided.
>  >
>  > * Stronger, verifiable evidence that applications based on pure-canvas
>  >   text editing can overcome the many cited limitations.
>  >
>  >

Received on Thursday, 2 August 2012 17:45:01 UTC