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

There are several questions of fact, as well as several assertions in
this decision that were not previously discussed, as far as I'm able to
determine. Therefore, on behalf of PF, I want to underscore the request
for additional time to respond on this decision.


Janina

Richard Schwerdtfeger writes:
> 
> Maciej,
> 
> There are a number of items I need to respond to in your decision.
> Unfortunately, I have other commitments this week. Consequently, I will not
> be able to provide you with a thorough response this week.
> 
> Rich
> 
> 
> Rich Schwerdtfeger
> 
> 
> 
> 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).
> - 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.
> 
> 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.
> 
> 
> == 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.
> 
> 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.
> 
> 
> == 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> == 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.
> 
> 



-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

The Linux Foundation
Chair, Open Accessibility:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Received on Wednesday, 25 July 2012 01:23:07 UTC