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

Response in <RSS></RSS>

Rich Schwerdtfeger
CTO Accessibility Software Group


                                                                           
             Maciej Stachowiak                                             
             <mjs@apple.com>                                               
             Sent by:                                                   To 
             public-html-reque         Richard                             
             st@w3.org                 Schwerdtfeger/Austin/IBM@IBMUS      
                                                                        cc 
                                       Steven Faulkner                     
             03/13/2010 12:44          <faulkner.steve@gmail.com>,         
             PM                        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 13, 2010, at 9:26 AM, Richard Schwerdtfeger wrote:


      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.


At least on Mac OS X, the visual results are that the caret disappears as
soon as I start dragging, and a selection appears instead. When I stop
dragging, the caret does not reappear. Instead, a selection remains. To the
best of my knowledge, this also matches what happens in the DOM -- you
either have a caret selection or a range selection, not both at the same
time. The caret is a special case of the selection, in the case where the
selection start and end points are the same. This also also matches how
carets and selections are treated in Mac OS X system APIs. I don't have
Windows handy right now to test, but I don't recall ever seeing a caret and
a selection appear at the same time.


      <RSS>I confirmed with Frank Olivier (Microsoft) that when you turn on
caret browsing the follows the end of the caret selection drag. Also, on my
Mac, although the caret does not render during selection. If you drag the
selection and then hit the right arrow key the caret appears at the end of
the selection. However, if you hit the down arrow it goes to the next line
at the X Position representing the start of the drag. We need to have the
screen magnifier follow the end of the selection and even if the caret is
not visible I feel you want to follow the end of the select or caret
location. The caret, during a selection should follow the end the selection
drag. It does on Windows for caret browsing mode. The Accessibility API
used to move the "point of regard - a UAAG 1.0 term", on systems I work on
do so by following the caret position and not the selection which is a
selection range vs. a location. I can't see having the magnifier following
a selection range as it could be the whole page.

</RSS>

Maybe I'm misunderstanding what you are saying.)


      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.


I don't follow. What's the "point of regard"? How can you follow the caret
when selecting text, if there is no caret when selecting text?

In the API you linked, there appear to be separate TEXT_CARET_MOVED and
TEXT_SELECTION_CHANGED events. That implies to me that changes to both need
to be reported, and that the appropriate one would be sent depending on
wether the selection is currently a caret.



      <RSS>The selection change, you are referring to pertains to a range
      and not a location. In my mind the caret should follow the end of the
      selection because this is where the user is operating. It is also
      important to have a consistent vehicle for maintaining point of
      regard.



      Here is the definition of Point of Regard from the UAAG 1.0 Glossary:

      The point of regard is a position in rendered content that the user
is presumed to be viewing. The dimensions of the point of regard may vary.
For example, it may be a point (e.g., a moment during an audio rendering
or a cursor position in a graphical rendering), or a range of text (e.g.,
focused text), or a two-dimensional area (e.g., content rendered through a
two-dimensional graphical viewport). The point of regard is almost
always within the viewport, but it may exceed the spatial or temporal
dimensions of the viewport (see the definition of rendered content for more
information about viewport dimensions). The point of regard may
also refer to a particular moment in time for content that changes over
time (e.g., an audio-only presentation). User agents may determine the
point of regard in a number of ways, including based on viewport position
in content, content focus, and selection. The stability of the point of
regard is addressed by guideline 5 and checkpoint 9.4..





      </RSS>



      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



requestDraw sounds like it would have the opposite of the intended effect
(i.e. request that the UA should draw the focus ring, always.) The boolean
return you suggest is in the draft already.

      <RSS> What I am suggesting is the author is making a request to draw
the focus rectangle when the value is set to "true". The user agent can
return a false value indicating that the author is not allowed to draw the
focus ring based on the points you made.


Regards,
Maciej