- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 18 Dec 2011 18:03:45 +0000
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Steve Faulkner <faulkner.steve@gmail.com>, chuck@jumis.com, Cynthia Shelly <cyns@microsoft.com>, david bolter <david.bolter@gmail.com>, dbolter@mozilla.com, franko@microsoft.com, Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org, Sam Ruby <rubys@intertwingly.net>
On Sun, Dec 18, 2011 at 4:25 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > USE CASE: Regarding hit testing, it is very, very simple. In ALL operating systems that support an accessibility API it is ESSENTIAL that a magnifier be able to determine the location of an accessible object on the screen so that a user may zoom to it. It has absolutely nothing to do with rich text editing Note Jonas mentioned text editors not rich text editing. They aren't quite the same thing. > USE CASE: Regardless of whether you are doing rich text or not canvas supports the ability to draw text on the screen. If you are creating a drawing object you will want the user to give it a label. To do that you have to provide them the ability to enter text. The user experience would be dreadful if you had to launch an HTML dialog box to enter it so authors will want to be able enter text using canvas for this basic purpose. The magnifier MUST be able to follow along. This use case does involve text editing, albeit not necessarily rich, and not necessarily as an app that is a text editor - could be some sort of diagram or map editor. Jonas, would editing labels on map count as a "text editor" in your book? > USE CASE: Expanding on the above, people will want to select text at times to replace text with new text on canvas even if it means pointing, highlighting as you drag your finger over the text, and typing over the text (we have no clipboard support in canvas). Again this use case does involve text editing. > 3. USE CASE for text baseline: As Steve indicated, the use cases for text baseline are in my change proposal. I will not repeat them here. "compute drawing rings bounds, bounds for highlighted text, and text caret position", if I've got it right. http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline e.g. If you render multiline text in canvas, some screen magnifiers will need to highlight the line of text under consideration. > Does anyone not understand these use cases? I would add that caret navigation through canvas content and partial selection of text in canvas content for copying are not strictly text editing, but could make use of features meeting these use caes. I'm not sure whether these activities fall under Jonas's rubric of "text editor" or not. -- Benjamin Hawkes-Lewis
Received on Sunday, 18 December 2011 18:04:23 UTC