Fw: Use of ARIA markup for rich text editing

I think David solved our caret problem:

<mark aria-selected="true"></mark>  would represent a collapsed selection
and therefore a caret similar to the terminology used in webkit and
Firefox.

This, in principle, seems to solve our problem with rich text editing. We
simply need to make sure we address the proper API mapping in the
accessibility API (I am cc'ing Steve and Cynthia as this may impact our API
mapping document for ARIA in HTML 5).

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group
----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 12/14/2010 04:16 PM
-----

From:	Richard Schwerdtfeger/Austin/IBM
To:	franko@microsoft.com, david.bolter@gmail.com
Cc:	Charles Pritchard <chuck@jumis.com>, public-canvas-api@w3.org
Date:	12/14/2010 03:41 PM
Subject:	Use of ARIA markup for rich text editing


Hi Frank, David

I spoke with Charles and I think we can reproduce the same functionality
with existing ARIA attributes on existing HTML elements in canvas using
aria-invalid:

http://www.w3.org/WAI/PF/aria/states_and_properties#aria-invalid

We could basically have:

<mark aria-invald="grammar"> See Spot fast run </mark>

or

<mark aria-invald="spelling"> See Spot fast run </mark>

or

<mark aria-selected="true"> See Spot fast run </mark>

This eliminates the need for any new HTML 5 tags. It uses existing ARIA
markup. We would simply need to define its API mapping in the HTML 5
accessiblity mapping document.

These can then be wired to the <canvas> UI and we don't need to make use of
any new API calls. Authors would be required to mark the areas accordingly.

Would you support this approach? To me this is low impact comparative to
any other solution we have now.

The only think we don't address is a replacement for the caret found in
contenteditable areas. So, to have a caret we would need to use either a
textfield or a contenteditable area - unless we add a feature.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group