Re: html5 editor responds to Canvas accessibility related bugs

  (this fell of the list, sorry list members)

On 10/5/2010 2:44 PM, Ian Hickson wrote:
> On Tue, 5 Oct 2010, Charles Pritchard wrote:
>> On 10/5/2010 1:58 PM, Ian Hickson wrote:
>>> On Tue, 5 Oct 2010, Charles Pritchard wrote:
>>>> Would you state that<canvas>   MUST NOT be used for rich text editing in
>>>> the HTML spec?
>>> Could you clarify the question? What do you mean by "must not"?
>> RFC 2119
>>
>> MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is
>> an absolute prohibition of the specification.
> If you mean, should it be non-conforming to write a Web page where a text
> editor is created using<canvas>, then I don't think the question is
> really meaningful. There's lots of ways that<canvas>  can be used for rich
> text editing that are quite accessible and have good appropriate uses,
> which don't need caret or selection APIs. Trying to make the spec
> explicitly disallow one kind of<canvas>  use and not another would just be
> an exercise in futility.

I'm glad we have some shared idea that "canvas" can be used for "rich 
text editing... and have good appropriate uses".

I'm still very much invested in Richard's sentiment, that there are 
deficiencies in current APIs which should be addressed.
I don't think these are "text editing" proposals:
 > > Bug10248 - Canvas requires a Caret Drawing call method
 > > Bug10249 - Canvas requires a content selection method

They're both very-much related to selection. Mobile Safari has excellent 
examples of content selection being used in an accessible manner. The 
current cursor position is zoomed in on, selection points are easily 
movable by the user. That's something we should hope to be able to 
accomplish using Web APIs.

This is a clear use case where selection and caret would be appropriate 
for accessibility purposes:
http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibilitynonav

If the use is navigating with their keyboard, and Firefox provides an 
example of Caret navigation, but anyway...
They're going to need to have visual signals as to where they are 
focused within the table element, so they may select content.

Currently, we can inform the DOM about selected ranges. We can make the 
data transferable with dataTransfer events. The only part we're missing 
is drawing the caret, and subsequent content selection imagery. 
Directionality is still important, as a user may be selecting bi-di content.

I'm sure there are additional use cases (I have a few relating to 
selecting multiple positioned elements for dataTransfer), where caret 
and content selection methods would be helpful to programmers working 
with event.dataTransfer. But those aren't directly relevant to 
public-canvas-api.

Can we agree that caret and selection are important for accessible 
navigation of the canvas sub-tree?


-Charles

Received on Wednesday, 6 October 2010 03:52:17 UTC