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

RE: drawSystemFocusRing in Canvas

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Thu, 25 Jul 2013 18:50:08 -0500
To: Suzanne Taylor <suzanne.taylor@pearson.com>
Cc: public-html-a11y@w3.org
Message-ID: <OFCA317A37.D50E948B-ON87257BB3.0081ADFC-86257BB3.0082EEE9@us.ibm.com>
Hi Suzanne,

response below. Note: I will out tomorrow and won't be able to respond
again until next week with any questions you might have. So, if you don't
get a response I am not ignoring you. :-)

Rich



Rich Schwerdtfeger



From:	Suzanne Taylor <suzanne.taylor@pearson.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
            public-html-a11y@w3.org,
Date:	07/25/2013 05:38 PM
Subject:	RE: drawSystemFocusRing in Canvas



I like the idea that no matter who customized the system focus ring (web
developer, user through OS setting, etc) that style will be used.

I have a concern/question about how the focus ring will be cleared:

According to the spec, drawSystemFocusRing actually draws onto the canvas:

      If the given element is focused, draws a focus ring around the
      current default path or the given path, following the platform
      conventions for focus rings.

      <rich>yes but it makes that function call in response to receiving a
      focus event. The path is defined by the author. </rich>

It doesn’t set up onfocus and onblur automatic events, like the presence of
an ordinary active element, which would be more like this:

<rich> Why not? Keyboard focus is in fallback content. If focus moves the
user agent should send the onblur event. The author would need to set up a
handler to erase the old ring. It knows how it computed the path the last
time. This is an authoring issue. GUIs work the same way.
</rich>

      Permanently associate the current default path or the given path with
      the given element, so that, as the given element gains and loses
      focus, focus indication is shown and hidden on the canvas and
      communicated to AT following the platform conventions for focus
      rings.

<rich> Well, to do this right the author may need to paint the background
again. It may not be that simple.
</rich>






So, would a Web developer use drawSystemFocusRing in a function triggered
by onfocus(), something like this:
      function myFocus(num){
                      rc.beginPath();

                      rc.moveTo(275,165);
                      rc.lineTo(415,165);
                      rc.lineTo(415,285);
                      rc.lineTo(275,285);
                      rc.lineTo(275,165);
                      rc.closePath();

                      rc.drawSystemFocusRing(document.getElementById
(‘thefallbackitem’));
      }
<rich>Yes, and there may be additional clearing and painting that goes
along with that.</rich>

If so, with each browser having different fallback styles, and with
possible end user customization, how will we know how to un-draw the focus
ring, which might actually overlap fairly complex backgrounds?

<rich>You track the focus related events and do your drawing for erasing
and drawing the focus rectangle. This will require, at times, painting the
backing over to address complex backgrounds. </rich>

Thanks,
Suzanne

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Thursday, July 25, 2013 11:03 AM
To: public-html-a11y@w3.org
Subject: drawSystemFocusRing in Canvas



I am working with Google on their implementing support for this feature.
One of the things we did not specify with greater clarity is how the focus
ring style is determined for the standard focus ring associated with a
fallback element.

Default Focus styling by default should be determined from the outline
style of the fallback element associated with the element drawn on the
canvas

http://www.w3.org/TR/CSS2/ui.html#dynamic-outlines


From CSS2:
"Graphical user interfaces may use outlines around elements to tell the
user which element on the page has the focus. These outlines are in
addition to any borders, and switching outlines on and off should not cause
the document to reflow. The focus is the subject of user interaction in a
document (e.g., for entering text, selecting a button, etc.). User agents
supporting the interactive media group must keep track of where the focus
lies and must also represent the focus. This may be done by using dynamic
outlines in conjunction with the :focus pseudo-class.


For example, to draw a thick black line around an element when it has the
focus, and a thick red line when it is active, the following rules can be
used:



:focus  { outline: thick solid black }
:active { outline: thick solid red }"


This would of course mean that should the author decide to change the
default focus style for the outline of that element that that style could
change on the physical canvas.


I would like to add informative text to the Canvas 2D API document that
states something on the order of (and this could be placed in a note):


Note:


The agents may use the <a href="
http://www.w3.org/TR/CSS2/ui.html#dynamic-outlines">CSS outlines around
focused elements</a> in determining the system focus style on fallback
elements to determine the standard system focus ring style drawn on the
canvas. This would mean that if an author were to override this style that
the appearance of the standard focus ring drawn on the canvas could reflect
this change in style.


Since this is non-normative text and would not require us to go back to
Last Call and because Google requested that we add informative text I would
like to propose adding this or similar to text to the current Canvas 2D API
CR document.


Rich









Rich Schwerdtfeger




graycol.gif
(image/gif attachment: graycol.gif)

Received on Thursday, 25 July 2013 23:50:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:34 UTC