ChangeProposals/CaretSelection

From HTML WG Wiki
< ChangeProposals
Revision as of 16:36, 7 February 2012 by Rschwer (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Modify existing Canvas 2D API caret and focus ring support to drive screen magnification

Summary

Modify the Canvas 2D API to properly handle caret, selection position, and focus rings to assist screen magnification products to support users with low vision in using canvas.

Rationale

The existing Canvas 2D API specification provides an API called DrawFocusRing() that has incomplete support for screen magnification tracking of focus rings, carets, and content selection. In speaking with some magnifier vendors they need access to the caret or selection position rectangle (constituting an edge) as well as the accessibility semantics of the corresponding object in the fallback content. The text in DrawFocusRing states minimal text that refers to a caret: "The given coordinate is used if the user's attention needs to be brought to a particular position (e.g. if a magnifier is following the editing caret in a text field)."

Authors should be forced to follow system settings as these are set by a user based out of personal preference. Personal preferences are set for a variety of reasons, the most serious being that the user simply cannot use the application because of an impairment. To address this issue government procurement standards, such as 508, require applications to support system font and color settings. If your application does not comply you fail purchasing requirements. It should be noted that, in our proposal, if no system setting has been set for focus ring then the drawFocusRing simply draws along the path as the author specified while at the same time updating the magnifier based on the focus ring.

The existing specification suffers from the following deficiencies.

  1. DrawFocusRing is a single API that is intended to drive both drawing of a focus ring while providing a caret position. Accessibility API services for caret position and focus rings are separate APIs as developers don't draw the caret and focus ring at the same time. Consequently, the API for each needs to be separated out.
  2. DrawFocusRing does not ensure that the focus ring, drawn, allows the browser to follow focus ring conventions for the OS platform that may also reflect user's preferences. It allows the author to execute a separate drawing function that would cause the author to draw focus using the standard drawing path but not drive magnification when that occurs. If the author sets canDrawCustom to true and the operating system has not specified out a focus ring is to be drawn, that drawing is turned over to the author. Therefore the specification allows the author to draw focus without driving magnification.
  3. Although DrawFocusRing provides for a caret position the user agent does not know whether it is supporting a caret position or a focus ring. The x, y attributes are required.
  4. DrawFocusRing, in the current specification, only allows the author to provide a point. At large magnification levels (4x-20x) a magnifier also needs to use the height and width of the caret, to be able to properly center the content in the screen. This was verified when speaking with Freedom scientific.
  5. DrawFocusRing does not address magnifier tracking of user content selection in canvas. Canvas authors will want to allow for content selection. Some user agents, like Internet Explorer, support caret tracking during selection whereas others, like Safari on the Mac, treat the selection position as a separate entity.
  6. DrawFocusRing's caret position support does not allow for an author to acquire caret blink rate settings that may have been set to prevent seizures.
  7. The existing DrawFocusRing text does not provide any guidance to user agent manufacturers as to how to use the necessary information to support accessibility API services.
  8. In the situation where we are dealing with text content, it is essential that we be able to access the text's baseline in order to properly compute the drawing path for a caret, selection position, or focus ring. This information is not provided in the canvas 2D API specification and requires additional computation.

In speaking with both Freedom Scientific and AI Squared both companies expressed the need to be able to track caret and focus ring changes. Browsers, like Internet Explorer 9, are using Direct2D on Windows and eliminating the ability to capture their traditional display driver or GDI drawing call interception techniques to capture the caret and the focus ring. On other platforms there is no vehicle to capture the draw these drawing calls. Furthermore, many believe this change is only meant to target rich text editing but in actual fact it is not. Canvas developers will at times introduce a caret or provide for content selection. Programmatic access is essential to drive magnification.

Details

We have introduce modifications to the Canvas 2D API Specification that are enumerated here:

  1. moved to setting of the caret and selection position to a separate API from DrawFocusRing to a separate API called setCaretSelectionPos that takes x, y, w, h parameters to define the caret selection position being reported to the browser to pass on the the platform accessibility API services. The additional width and height of the caret will allow user agents to better assist screen magnifiers in positioning the zoom position at large magnification levels with combined with the semantic information provided by the corresponding element passed from fallback content.
  2. removed the optional canDrawCustom property from DrawFocusRing. The author should already have already integrated the custom drawing scheme into the drawing path. Furthermore, even if the system is able to draw the FocusRing it needs the drawing path to compute the path of the focus ring. Also, if the system has not configured the system in a current manner, returning false and passing the drawing function off to the author will cause the author to draw the focus ring without telling the magnifier where it is.
  3. modified drawFocusRing to provide user agents with information on how to use the drawing path to drive magnifiers for focus ring. More complete details will that address API or platform specific issues will need to be addressed in the HTML to Platform Accessibility APIs Mapping Guide.
  4. Separated Focus and Caret Selection Management into two separate sections. Not all selected content has to receive focus.
  5. Added a function to get the caret blink rate to reflect system settings set by users that may have been done to prevent seizures.
  6. Added the property baseline to TextMetrics to acquire the baseline of text.
  7. Re-wrote code example, emphasizing the fallback content as an accessible shadow DOM, that was in section 10 and moved it to section 11 of the specification. The previous code was non-executable.

Impact

The impact to the specification is minor and it minimizes the impact to authors while producing a more reliably accessible solution.

Positive Effects

  • Provides for both screen magnifier tracking of caret and selection position changes on canvas separate from focus rings to allow a user agent to drive the appropriate platform accessibiity APIs.
  • This is a much better solution than Proposed here in response to Issues 74 and 75, listed under Issue 105, as we completely separate caret and selection accessibility support from drawFocusRing().
  • Provides the ability for the author to query system caret blink rate settings so that they may avoid causing seizures as a result of high blink rates.
  • Changes the caret information provided to a screen magnifier to include width and height information to aid magnifiers in zooming around a caret or selection position.
  • Caret and Selection position APIs are lite weight. The APIs support screen magnification without restricting the user's drawing ability. This also allows this same API to drive magnification zooming when the author wants to draw the magnifier zoom to other drawing constructs.
  • Fixes the loop holes in drawFocusRing() that could allow an author to not direct the screen magnifier to the focus ring
  • Provides a vehicle to get the baseline for text, as requested in defect 11342 to facilitate focus ring drawing an caret/selection positioning in and around text

Negative Effects

  • Caret and Selection are not integrated with actual drawing. However, it is questionable that we could produce something that is rich enough for canvas

Risks

  • Although outside the scope of this issue, this proposal does not address another need for screen magnification involving conveying screen screen coordinates of all content rendered from the fallback content on canvas. We have not yet come up with a way to do this without considerable impact to authors. One way to do this would be to provide an API here in the Canvas 2D API specification. This could be addressed in a later version after last call for HTML 5.

References