Canvas 2D API changes

Hi James,

I made modifications to our change proposal for the Canvas 2D API which I
hope are in line with your comments. Before I circulate these to the wider
group I would like your feedback. Please see the attached file and the
justification below.

1. I modified the drawFocusRing method to only take an element. My
reasoning:

- You requested that authors use the drawing path as the focus ring.
- If you are supplying a ring you can specify how it is drawn.  If you
specify the  line drawing/fill characteristics the user agent can draw the
ring
- If the OS specifies a drawing ring standard it needs to be honored
regardless of what the author would like as the user has asked that
- There is no need to pass an x,y coordinate or width and height of the
focus rectangle to drive magnification. The user agent can compute the
bounding rectangle and supply it to the accessibility services information
for that object. The AT will be determining what element they should be
focused on based on the focused element in the fallback content or the area
map (more on that later). A screen magnifer will then adjust where it
magnifies based on the object type and its bounding rectangle. For example,
you might want to center the magnifier in the middle of a pushbutton but
for a menu item you might want to align it with the left edge of the
rectangle. The bounding rectangle can be computed by the drawing path.

2. I made and and attempt to clarify setCaretRectPosition(). There appeared
to be confusion regarding the use of Rectangle and it meaning the rectangle
encompassing the selected text. What is important is to allow the track the
position they are pointing to during a selection on the screen.

3. I removed the author guiding guidance from the user agent processing
procedure for setCaretSelectionRect. I agree this was the wrong place for
this.

4. I entered two defects against the Canvas2D API requiring the need for a
caret and selection drawing call function per a request from Ian. If these
methods were provided we could easily handle the caret and selection
position tracking under the covers so the author does not need to worry
about an additional call to drive magnification (setCaretSelectionRect).
These defects (10248 and 10249) if provided and adapted to support platform
accessibility services would allow us to remove the setCaretSelectionRect
API and the caretBlinkRate call. The platform blink rate should be
addressable under the covers to prevent seizures.

5. When I referred to the focused element in drawFocusRing() and
setCaretRectPosition() expanded the element definition to cover fallback
content or an area map element. The group would like to have <canvas>
support fallback content bindings to canvas as well as an area map (Charles
McCathienveville's proposal). The reason is that the group believes authors
will want to use different techniques in different scenarios. For example,
a canvas be used to render a checkbox. This can be made easily accessible
with an area map such as below. In this scenario focus rectangles can also
be handled by the area map.

<canvas width="300" height="400" usemap="#myMap">
  <map id="myMap">
   <form>

    <label for="one">option one
     <input type="checkbox" shape="path" name="one"
      coords="M 20 50 c -20 20 60 20 50 0
       c -20 -20 0 -40 0 -40 c -20 -20 -20 20 -50 0 z">
    </label>

    <img role="checkbox" shape="rect" id="two"
     src="squiggle.png" alt="option two" tabindex="0"
     coords="20 150 70 180">

    <area role="checkbox" alt="option 3" shape="circle"
     coords="50 200 50">

   </form>
  </map>
 </canvas>

(See attached file: 2dcontext10-July-28.html)

Rich Schwerdtfeger
CTO Accessibility Software Group