W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2013

Revised text action items for me from December 16, 2013 Canvas A11y meeting

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Mon, 23 Dec 2013 12:29:02 -0600
To: Canvas <public-canvas-api@w3.org>, "Jay Munro" <jaymunro@microsoft.com>, "Jatinder Mann" <jmann@microsoft.com>
Cc: "Mark Sadecki" <mark@w3.org>, "Dominic Mazzoni" <dmazzoni@google.com>, "Rik Cabanier" <cabanier@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <OF9F3B6B8F.C4FD16FC-ON86257C4A.00604FA0-86257C4A.0065887D@us.ibm.com>

These change to drawSystemFocusRing() intended to address defects as
actioned by the December 16, 2013 accessibility meeting (

Revised definition of drawSystemFocusRing's purpose (section 12 of the
spec) - new suggested text:

Inform the user of the canvas location the fallback element, based on the
current default path. Additionally, if the the given element is focused,
draws a focus ring around the current default path following the platform
conventions for focus rings defined by the user agent. User agents often
implement focus drawing following system conventions.

These revised programmatic steps actions to address bug 2398 and add a bug
for 2462 ( have included revised wording below for the editors) below and I
will link to this post in both defects:

2398 - remove optionally, and add a note to explain the purpose of this
2462 - Inform assistive technoogies of the location, even when it does not
have focus ( this

       1.	If element is not not a descendant of the element with whose
context the method is associated, then abort these steps.

   2.	Inform the user that the focus is at the location given by the
      intended path. User agents may wait until the next time the event
      loop reaches its "update the rendering" step to optionally inform the

   Note: This step is intended to provide inform the user of the location
      of the element on canvas to support accessibility services. For
      example, a screen magnifier may use this information to respond to a
      user request to zoom to the location of the object in fallback
      content to assist a low vision user.

   3.	If element is not focused then abort these steps.

   4.	If the user has requested the use of particular focus rings (e.g.
      high-contrast focus rings), or if the element would have a focus ring
      drawn around it, then draw a focus ring of the appropriate style
      along the intended path, following platform conventions.

      Some platforms only draw focus rings around elements that have been
      focused from the keyboard, and not those focused from the mouse.
      Other platforms simply don't draw focus rings around some elements at
      all unless relevant accessibility features are enabled. This API is
      intended to follow these conventions. User agents that implement
      distinctions based on the manner in which the element was focused are
      encouraged to classify focus driven by the focus() method based on
      the kind of user interaction event from which the call was triggered
      (if any).

      The focus ring should not be subject to the shadow effects, the
      global alpha, or the global composition operators, but should be
      subject to the clipping region. (The effect of transformations is
      described above and varies based on which path is being used.)


Rich Schwerdtfeger
Received on Monday, 23 December 2013 18:29:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:55 UTC