- 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
Attachments
- image/gif attachment: graycol.gif
Received on Thursday, 25 July 2013 23:50:51 UTC