Re: Request to re-open issue 131 -USE CASES, USE CASES, USE CASES

Jonas,

Regarding the IME, there are lots of applications on the Web that are not
concerned about internationalization. IBM is not a company that produces
those types of apps and neither is Mozilla. What I am simply saying is that
for many application developers this is not a concern - not that it is not
important. That said, the apps that are not internationalized are put out
there and people who could use the languages they do support are left out
in the cold if they had a disability. IBM constantly buys companies and in
many many cases we have to deal with the internationalization issue.

Rich



From:	Jonas Sicking <jonas@sicking.cc>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
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, 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>
Date:	12/19/2011 09:20 AM
Subject:	Re: Request to re-open issue 131 -USE CASES, USE CASES, USE
            CASES



On Sun, Dec 18, 2011 at 8:25 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
  2. Caret and Selection Tracking

  USE CASE: If you are a magnifier you must be able to follow the location
  on the screen where you are typing a piece of text or you are pointing to
  select content. Remember, a magnifier's view of the screen may be VERY
  SMALL. The magnifier needs to follow along as you type. That is why we
  submitted the change request before and why it was approved and why I had
  agreement from David Bolter, Microsoft, Steve Faulkner, etc. to submit
  the first proposal that was accepted.

  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.

  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).



So the last use case seems reasonable to me to solve. But the first two
appear to be only for text editing and so falls into the category that *I*
am not interested in solving at this time. At least not until someone has
shown that a proper editor can be built for them.

Note that it's very possible to overlay a text box on top of a canvas such
that it renders just like any other part of the canvas. No need to "launch
an HTML dialog box". The UI can be indistinguishable to if the text was
drawn with canvas APIs.
  4. USE CASE for exposing a caret blink rate:

  OS platforms allow the configuration of a blink rate by a user. User's
  configure blink rates to avoid epileptic seizures. The blinking problem
  is not limited to text carets. We need to expose this information so that
  a canvas author can avoid having a problem.


This too only seems useful for text editing based on the use case you've
presented here.

I also don't buy the argument that people don't need IME any more than I
buy the argument that people don't need accessibility.

/ Jonas