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

Maciej Stachowiak <mjs@apple.com> wrote on 07/17/2012 08:56:10 PM:

> From: Maciej Stachowiak <mjs@apple.com>
> To: "public-html@w3.org WG" <public-html@w3.org>,
> 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.
>
> http://www.w3.org/html/wg/tracker/issues/205
> http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised
> http://www.w3.org/wiki/No_edit_change_proposal_for_canvas_text_editing
> http://www.w3.org/2002/09/wbs/40318/issue-205-objection-poll/results
>
>
> == 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 (
http://www.w3.org/wiki/No_edit_change_proposal_for_canvas_text_editing)
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.
http://www.youtube.com/watch?v=wdqgSB9axZQ


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:
http://www.w3.org/TR/2012/WD-ime-api-20120524/

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:
>
>    http://www.w3.org/wiki/No_edit_change_proposal_for_canvas_text_editing
>
> 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:
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised 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 HTML.next
and save proposal
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised 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.
>
>