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
>