Re: Solution to grammar, spelling, and

Hi Maciej,

I forgot to add that there is NO API to get a grammar or spelling error in
markup in contenteditable sections in JavaScript. So, even if we could use
Apple's engine for processing spelling and grammar errors it is not being
made available to a web application drawing on canvas to be able to convey
the error on the physical drawing surface. A cloud based application that
wants to render these errors on canvas is forced to use their own services
for grammar and spell checking.

No API has been made available as it was deemed that this would pose a
privacy or security issue. I don't buy the argument but others do.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Richard Schwerdtfeger/Austin/IBM@IBMUS
To:	Maciej Stachowiak <mjs@apple.com>
Cc:	Charles Pritchard <chuck@jumis.com>, david.bolter@gmail.com,
            franko@microsoft.com, public-canvas-api@w3.org,
            public-html-a11y@w3.org
Date:	02/07/2011 05:57 PM
Subject:	Re: Solution to grammar, spelling, and
Sent by:	public-html-a11y-request@w3.org



I just saw this. Apologies Maciej.

1. If an author of a canvas application wished to do text editing and a
screen reader were going to find out where the grammar or spelling errors
are they would need to find it in the content. That can be done in
contenteditable sections or and author of a cloud-based application, like
Google Docs, may wish to have their own spelling or grammar checker that is
consistent across client platforms. Content could be passed to a web
service for analysis and there is no need to depend Apple's own design. I
can't imagine Microsoft Office using the same spelling and grammar checker
as Apple's office suite. Am I right?
2. A screen magnifier needs to know where know the location of spelling and
grammar errors so that it can position the user at those locations during
zooming. The canvas fallback content, used to make canvas accessible, does
not have coordinates that match the screen locations where they actually
appear on canvas.
3. Regarding caret and selection we agree that we could use the normal
scripting API for the selection. However, it would be nice if browser
manufacturers could use the same API. IE matches no other browser here.
4. Caret/Selection When the user moves the caret or the selection position
on the screen the magnifier needs to follow the screen position of the
caret or the point you are pointing your finger or mouse to perform the
selection. We need the ability for the author to pass that information to
accessibility API services in the browser so that a magnifier can follow
along.


Rich Schwerdtfeger
CTO Accessibility Software Group

Inactive hide details for Maciej Stachowiak ---01/06/2011 06:51:42 PM---I
don't understand the goal of this interface. Grammar Maciej Stachowiak
---01/06/2011 06:51:42 PM---I don't understand the goal of this interface.
Grammar and spelling checking are normally system ser

From: Maciej Stachowiak <mjs@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-canvas-api@w3.org, franko@microsoft.com, david.bolter@gmail.com,
Charles Pritchard <chuck@jumis.com>, public-html-a11y@w3.org
Date: 01/06/2011 06:51 PM
Subject: Re: Solution to grammar, spelling, and




I don't understand the goal of this interface. Grammar and spelling
checking are normally system services (at least, on Apple's platforms this
is true). The flow you would need to integrate them with canvas would be to
call into the OS to find out what words are misspelled or what phrases have
incorrect grammar. The actual UI offered in native apps goes beyond just
drawing error markers and also includes dialogs that let you step through
errors and fix them. I don't understand how this proposal fits with that
flow.

For the caret and selection aspects - the DOM already has an API to specify
a selection range. It seems like you could easily put the selection inside
the canvas subtree. I don't see what this use of the <mark> element adds.

Regards,
Maciej

On Jan 6, 2011, at 4:28 PM, Richard Schwerdtfeger wrote:

      So, over the break we (David, Charles, and I) discussed a way to
      address the grammar, spelling, and caret tracking issues in the
      canvas subtree without having to introduce new HTML tags or requiring
      exposing new APIs that provide this information to canvas application
      authors having to synch the canvas to the canvas subtree.

      The alternative solution is to use ARIA with some slight
      modifications:

      In the canvas subtree we would simply make use of aria-invalid which
      already exposes grammar and spelling errors and it is a global
      attribute in ARIA 1.0:

      <mark aria-invalid="grammar"> See run Spot. </mark>
      or
      <mark aria-invalid="spelling">See Spot Rn. </mark>

      As for selected content we simply do apply aria-selected="true" to
      any content:

      <mark aria-selected="true"> ... </div>

      The modification would be to make aria-selected an ARIA global
      attribute and address the accessibility API mapping for it. This is
      very straight forward.

      For a caret we simply have a collapsed section:

      <mark aria-selected="true"></mark>

      This is all very clean, requires minimal impact to the existing
      browser implementations and in fact puts more control in the hands of
      cloud-based offerings where they are not limited to what the browser
      is doing for them in contenteditable sections.

      Frank would you and the IE team support this approach? I would like
      to discuss this on Monday's call as well.


      Rich Schwerdtfeger
      CTO Accessibility Software Group