W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2013

Re: Fw: Re:

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 23 Sep 2013 15:12:17 +0000
Message-ID: <CAGN7qDDHH+NmKQzmEQ8y2S-V0+T7a+Nt5g=ddeJaS9kZwhgNEw@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: Paul Cotton <Paul.Cotton@microsoft.com>, janina@rednote.net, faulkner.steve@gmail.com, public-html-a11y@w3.org, jbrewer@w3.org, dbolter@mozilla.com, franko@microsoft.com, James Craig <jcraig@apple.com>, Dominic Mazzoni <dmazzoni@chromium.org>

yes, an API with the same name was implemented but it is not following the
It doesn't seem like this would pass the bar as an implementation unless we
update the spec.


On Mon, Sep 23, 2013 at 6:42 AM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> Paul, Janina,
> I was correct in stating that drawCustomFocusRing() was implemented in
> Chrome for both Windows and Mac. So, we have one implementation of BOTH
> drawSystemFocusRing and drawCustomFocusRing().
> As Rik stated, the Path object does not have a full implementation and the

> for Canvas 2 is to introduce a Shape object to support magnifier location
> information.
> Rich
> Rich Schwerdtfeger
> ----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 09/23/2013 08:38 AM
>  -----
> From: Dominic Mazzoni <dmazzoni@chromium.org>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
> Cc: Rik Cabanier <cabanier@gmail.com>
> Date: 09/23/2013 01:11 AM
> Subject: Re:
> Sent by: dmazzoni@google.com
> ------------------------------
> On Fri, Sep 20, 2013 at 4:28 PM, Richard Schwerdtfeger <*schwer@us.ibm.com
> * <schwer@us.ibm.com>> wrote:
>    Hey Dominic,
>    When we talked you said you had implemented both drawSystemFocusRing
>    and drawCustomFocusRing. I only tested with drawSystemFocusRing.
> That's correct, they're both implemented.
>    Rik thought there was some problems with the custom focus ring
>    function.
>    Is that still the case and if so what is the concern. Other than
>    driving the magnifer I would think this basically involved calling stroke().
> I'm going by the spec from here: *
> http://www.w3.org/TR/2dcontext/#dom-context-2d-drawcustomfocusring*<http://www.w3.org/TR/2dcontext/#dom-context-2d-drawcustomfocusring> -
> let me know if that isn't the correct document. Here's what it says for
> step three of drawCustomFocusRing.
> *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 intended path, and set result to false.*
> As best as I can determine, no operating system exposes such a preference
> for high-contrast focus rings. Assistive technology like ZoomText or MAGic
> just draw their own additional focus rings, they don't tell applications to
> draw high-contrast focus rings. While in theory it's possible for a browser
> to add that as a user preference, there are no plans to do so at this time.
> Because of all this, it seems like this part of the spec isn't currently
> useful and should be removed.
> So, given that such a preference never exists, Chrome never draws anything
> when you call drawCustomFocusRing. It just updates assistive technology and
> returns false every time.
> It's still useful - but the name no longer makes sense. Something like
> notifyFocusRingPath might make more sense.
> I don't understand why we would ever call stroke() - can you explain how
> that's implied by the spec?
> - Dominic
Received on Monday, 23 September 2013 20:52:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:29 UTC