W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2011

[whatwg] drawFocusRing Review

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 05 Aug 2011 10:49:20 -0700
Message-ID: <4E3C2D20.9010708@jumis.com>
The current description of draw*FocusRing does not have "inform the 
user" in the correct priority.
It currently follows cases where the user should be informed, but the 
steps have been aborted.

Please review the following an provide feedback. This attempts to serve 
the use cases put
forward for focus ring management. In the first case, the system manages 
the focus ring,
using its own style or using the style set out by the current canvas 
context. The canvas
is not dirtied, though the author does have an opportunity to continue 
drawing focus indicators
onto the canvas.

In the second example, it is up to the author to decide on what 
visualizations they will use.
They will likely draw to the canvas, but they may decide to handle the 
visualization differently (such
as moving another canvas layer over the current canvas, and painting a 
bounding box).

In both examples, the accessibility api is informed of the current focus.


Change proposal follows:


The |drawFocusRing(element)| method, when invoked, must run the 
following steps:

 1.

    If the element is not focused or is not a descendant of the element
    with focus, then return false and abort these steps.

 2.

    If supporting accessibility, inform the user that the focus ring is
    at the location computed from the bounds of the path. User agents
    may wait until the next time the event loop reaches its "update the
    rendering" step to inform the user.

 3.

    If the user has requested the use of particular focus rings (e.g.
    high-contrast focus rings) then draw a focus ring of the appropriate
    style along the 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.

 4. Otherwise, draw a focus along the path using the current path style
    settings.

    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.

 5.

    Return true.

The |drawCustomFocusRing(element)| method, when invoked, must run the 
following steps:

 1.

    If the element is not focused or is not a descendant of the element
    with focus, then return false and abort these steps.

 2.

    If supporting accessibility, inform the user that the focus ring is
    at the location computed from the bounds of the path. User agents
    may wait until the next time the event loop reaches its "update the
    rendering" step to inform the user.

 3.

    Return true.
Received on Friday, 5 August 2011 10:49:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC