W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2010

Re: Fwd: Draft Revisions to Canvas 2D Context API to drive magnification

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 21 May 2010 16:33:24 -0600
To: Eric Carlson <eric.carlson@apple.com>
Cc: James Craig <jcraig@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html-a11y-request@w3.org, Frank Olivier <franko@microsoft.com>, david.bolter@gmail.com, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, surkov.alexander@gmail.com
Message-ID: <OF085A6819.FC549D01-ON8625772A.006FEF18-8625772A.007BE865@us.ibm.com>

Hi Eric and James,

It would be good to have either you or James on the canvas api call Monday.

I have some questions/comments:

1. The reason I chose only an x, y position is we felt the rectangle could
be determined from the associated object. That said, I can see why a
polygon would be more powerful.

Frank, David, Alex, Are you on board with supporting a polygon? Essentially
I would supply a collection of vertices for which would cover the polyline.
We would then need to convert that to the objects bounding rectangle in the
accessibility API.

2. Caret position - This is solely for magnifier tracking. So,  ...

- You only need to follow the last point of regard position. You can't have
a magnifier magnify in two places. So, why do want to specify ranges. I
think this unnecessarily complicates the problem.

- Why does it matter what type of cursor is drawn? Were you looking for
some additional functionality to drive a screen reader? This would be a new
requirement. Also, we are not asking the system to draw cursor and the
canvas 2D context API does not have an API for configuring the cursor which
leads me to believe this is handled outside the canvas API and can be
processed by normal accessibility API mapping by the browser. I would want
to hear from Microsoft to see if this is something that they also want this
for Windows. Mac and Windows are different and I am not sure we can get a
matching set of system caret/selection types. I am thinking we could do
without this functionality.

Also, please be sure to copy the canvas API list on this topic as well.

Thank you for the feedback,


Rich Schwerdtfeger
CTO Accessibility Software Group

             Eric Carlson                                                  
             le.com>                                                    To 
             Sent by:                  HTML Accessibility Task Force       
             public-html-a11y-         <public-html-a11y@w3.org>           
             request@w3.org                                             cc 
                                       James Craig <jcraig@apple.com>      
             05/20/2010 07:43          Fwd: Draft Revisions to Canvas 2D   
             PM                        Context API to drive magnification  

  I am re-sending this for James as he isn't subscribed to public-html-a11y
so his attempt bounced.


Begin forwarded message:

From: James Craig <jcraig@apple.com>
Date: May 20, 2010 3:31:44 PM PDT
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: public-canvas-api@w3.org, public-html-a11y@w3.org
Subject: Re: Draft Revisions to Canvas 2D Context API to drive

There is a way for Zoom to follow focus/caret position that could be
implemented for this proposal. We're looking into how much effort this
would involve for WebKit, but I don't have anything to report on that now.

Initial feedback for the proposed methods:

1. The focus ring should be a set of coordinates or a shape rather than a
single xy coordinate. At a minimum, it should be rect(x1, y1, x2, y2), but
it'd be better to use a standard shape as the parameter, e.g. line,
rectangle, ellipse, or polygon... Poly would allow not only non-standard
shapes, but would also provide an easy way to implement focus rings for UI
elements that appear skewed or rotated.

2. Caret position should likewise have more than one coordinate or shape
(s), especially since I assume this is intended to work for both selection
ranges as well as unselected caret position. Perhaps a some optional
parameters such as cursor type (I-beam, block, etc.), orientation
(vertical, horizontal LTR, horizontal RTL), and maybe language/locale (Are
there any language- or locale-specific cursors? I don't know.)

On Apr 29, 2010, at 2:25 PM, Richard Schwerdtfeger wrote:

      Hi Maciej,

      I have not heard back from Apple on this proposal. Please take a look
      at the proposal (attached HTML file) and let me know if this will
      work for the Mac. I think I addressed your issues and would like your

      We have an MSAA API call on Windows which we can call to set the
      Caret Position so that a magnifier can can follow it which can be
      used by IE and FF.

      I don't know if you have a similar API for the Mac where the
      selection position could drive the magnifier.



      Rich Schwerdtfeger
      CTO Accessibility Software Group
      ----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 04/29/2010
      04:17 PM -----
 Sent by:                 <ecblank.gif>                                    
 public-canvas-api-reques                                               To 
 t@w3.org                           <ecblank.gif>                          
                                    Frank Olivier <franko@microsoft.com>,  
                                    Janina Sajka <janina@rednote.net>, "   
 04/11/2010 06:49 PM                public-canvas-api@w3.org" <            
                                    public-canvas-api@w3.org>, Steven      
                                    Faulkner <faulkner.steve@gmail.com>,   
                                    Draft Revisions to Canvas 2D Context   

      Sorry it took so long for me to get this draft out. Too much
      traveling going on. Please take a look and provide feedback.

      The edits reflect:

      - Separate caret/selection from drawFocusRing
      The Mac does not support caret tracking during selection so this
      needed to be allotted for.
      - Expose the caret blink rate via 2D canvas API. Frank indicated
      Windows has a 500 millisecond defult blink rate a. Carl Carlson
      (Apple) indicated a default blink rate of 560 milliseconds. I
      provided information for authors regarding average default blink
      rates should the value returned be negative 1.
      - Change the name of canDrawCustom and clean up its definiton which
      according to Maciej is "want to draw custom unless Special Focus Ring
      Setting is in Effect"

      David Bolter: From the Firefox perspective we still need to see that
      the caret/selection location can be properly mapped to the
      accessibility API as is. Currently, the caret position is a logical
      one in IA2 and I believe the caret pixel position is calculated from
      the character font offset and the bounding rectangle of the text. We
      may need to move the system caret. I am trying to find the old
      Windows API for that.

      Frank: Please see if we can map the pixel position accurately, when
      provided, from the accessibility API. Windows used to have an MSAA
      notification for driving a magnifier based on screen position. I
      don't know if this is still used when using UIA Express.

      Maciej or James: Same question for Mac regarding the caret/selection

      (See attached file: 2dcontext10-Apr-11.html)

      Rich Schwerdtfeger
      CTO Accessibility Software Group(See attached file:


(See attached file: pic12933.gif)

(image/gif attachment: graycol.gif)

(image/gif attachment: pic25614.gif)

(image/gif attachment: ecblank.gif)

(image/gif attachment: pic12933.gif)

Received on Friday, 21 May 2010 22:33:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:26 UTC