Re: change proposal: Provide accessibility implementation information (in the Canvas 2d Context specification) for focus rectangle and caret

Response between <Rich></Rich>

Rich Schwerdtfeger
CTO Accessibility Software Group


                                                                           
             Maciej Stachowiak                                             
             <mjs@apple.com>                                               
                                                                        To 
             03/11/2010 11:37          Richard                             
             AM                        Schwerdtfeger/Austin/IBM@IBMUS      
                                                                        cc 
                                       Steven Faulkner                     
                                       <faulkner.steve@gmail.com>,         
                                       public-canvas-api@w3.org, HTMLWG WG 
                                       <public-html@w3.org>, HTML          
                                       Accessibility Task Force            
                                       <public-html-a11y@w3.org>,          
                                       public-html-a11y-request@w3.org     
                                                                   Subject 
                                       Re: change proposal: Provide        
                                       accessibility implementation        
                                       information (in the Canvas 2d       
                                       Context specification) for focus    
                                       rectangle and caret                 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





On Mar 11, 2010, at 7:43 AM, Richard Schwerdtfeger wrote:



      Hi Maciej,

      First, this is great feedback. I tried to stay in line with what was
      in the 2D Context draft that was out there, which in the fine print,
      indicated that the focus rectangle was also used for caret. It was
      unclear how much of the drawFocusRing() was implemented and I tried
      not to break things. So, I also had problems with reusing the same
      method.

      Here is the the text in the existing text that I am referring to:
      "The position of the center of the control, or of the editing caret
      if the control has one, should be given in the x and y arguments."

      So, it appears you are in agreement with simply having caret API that
      says setCaretPosition with a set of coordinates. As it states it
      would be bound to an element in the subdom which has a logical
      character position which the author would synch with. This we have in
      the proposal. I will simply separate them out.


Why setCaretPosition rather than setSelectionPosition? It seems to me that
screen magnifiers or the like may be interested in the screen location of
non-caret selections too.


<Rich>When text is selected it is usually following the caret position.
Accessibility APIs that I work with drive focus by following the caret
positon. For example, click and hold your mouse on the email you are
writing and then drag. When you click and hold the caret is moved to that
location. When you then drag the caret moves with the selection and
finishes up where you release. The magnifier should follow the caret.


Here is the caret move event from IA2:


http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_event_id_8idl.html#e26846b6d521727ab696d20c3f43c0b51d10f0c96c8c085baa648f166866d8c1


When selection changes it is usually for a range of text. So, really when
you are selecting text you should be following the caret or point of
regard. This would then need to be synched with the caret location in the
DOM sub tree.


<Rich>


      Second, if we require the author to do all the caret drawing I see a
      problem with not honoring blink rate settings that the author does
      not have access to. If the blink rate is high enough (greater than 3
      times a second) this may call seizures in some users. Should we not
      provide the ability for the user agent to override the drawing in
      some way?


We may have to expose the blink rate. I think it would be hard for the UA
to properly handle the blinking, because in general content may overlap the
caret, but canvas has no data model other than a bitmap. For carets in
native controls, the UA has to ensure that overlayed content is drawn over
the caret, but in the canvas case, it would be the responsibility of the
Web content.


<Rich> I agree that it will be hard for the UA to handle the blind rate. I
will add an API to query the blink rate </Rich>



Third, what I and others are struggling with is canDrawCustom on
drawFocusRing():

"If the canDrawCustom argument is true, then the focus ring is only drawn
if the user has configured his system to draw focus rings in a particular
manner. (For example, high contrast focus rings.)"

This does not make sense. The parameter, my name, indicates that the author
can draw a custom focus rectangle. It would make more sense to say that the
focus ring is drawn, by the user agent, only if the user has configured the
system to draw focus rings in a particular matter. ... meaning the user has
configured the desktop to draw focus rings in a standard way and the author
should not override that. Do you agree?


canDrawCustom is a bit of a funny name. I believe the intent of the
parameter is as follows:

- If canDrawCustom is false or omitted, the UA takes care of drawing the
focus ring, no matter what. This is the simplest form of the call to use.

<Rich> That makes sense </Rich>

- If canDrawCustom is true, then the Web application is indicating its
intent to draw the focus ring in a custom way; but if the UA would draw
focus rings in a way that respects a special accessibility setting, such as
high contrast, then it still does the drawing. The Web application can tell
whether it should do its custom focus ring drawing from the return value.

So canDrawCustom really means something like
wantToDrawCustomUnlessSpecialFocusRingSettingIsInEffect, but that's a bit
verbose. Perhaps there is a different good short name for the parameter.

<Rich> I recommend we change it to requestDraw and add the caveats you
indicate ... The default would be false which would leave the drawing up
the user agent to draw the focus ring. If it is true the author is
requesting to draw the focus ring. The drawfocusring should return a
boolean attribute to indicate to the author that they may draw the focus
ring. If the drawFocus method returns false it indicates to the author that
the user agent has decided to draw the focus ring due a user experience
setting such as for a high contrast focus ring. </Rich>


Regards,
Maciej