- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 15 Sep 2011 11:09:07 -0700
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- CC: mjs@apple.com, david.bolter@gmail.com, public-canvas-api@w3.org, public-html-a11y@w3.org
- Message-ID: <4E723F43.8050308@jumis.com>
To be clear, I just meant that Tab was OK with the textBaseline part of the proposal: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/033046.html I did not receive feedback on the focus ring changes. On 9/15/2011 10:58 AM, Charles Pritchard wrote: > Tab Atkins seems OK with the text baseline proposal, > as I ran it by the WHATWG mailing lists. > > The primary change with drawFocusRing is to ensure that the > accessibility information > is shared earlier in the process. There were conditions where a focus > ring would be drawn, > but the AT may not be notified. This was likely just a spec error, as, > the focus ring is often > tied into the accessibility tree, and would share it with the AT > regardless. > > Good luck with this. Hopefully we'll see the WHATWG spec merge back > with the W3C spec next year. > > > -Charles > > > On 9/15/2011 10:17 AM, Richard Schwerdtfeger wrote: >> >> Maciej, >> >> I created a Change Proposal to address the separation of >> DrawFocusRing into two methods and provided additional information >> pertaining the chairs had requested for text baseline. I tried to use >> as much as I felt was correct from the changes Ian made to the WhatWg >> spec., including the way he allowed for AT to be integrated with the >> browser as we will see with Chrome going forward. I felt there were >> some problems with Ian's spec. which I did not enumerate as the >> change proposal is written against the W3C spec.: >> >> - He assumed that all fallback contented needed to support the canvas >> element would need to be descendant of the canvas element. There will >> be times, such as hidden context menus, where content may reside >> hidden at the end of the DOM as transparent fallback content. >> - Ian's change still allowed the condition in drawCustomFocusRing >> such that if a system setting was not available to draw a focus ring >> in a certain style that the function could return allowing the author >> to create a new path for the focus ring with different styling. The >> new path may not match the path passed to browser and thus the >> magnification solution >> - drawCustomFocusRing should draw a custom focus ring and not adhere >> to system settings for styling as it is a custom focus ring. We have >> provided a drawStandardFocusRing function. >> >> Please provide feedback before take this to a more formal change >> proposal submittal. Charles Pritchard tried to get Ian to give >> feedback on the changes to DrawFocusRing on the WhatWg discussion >> list for weeks but received no response. >> >> http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline >> >> >> Thanks you, >> >> Rich >> >> >> Rich Schwerdtfeger >> CTO Accessibility Software Group >> >
Received on Thursday, 15 September 2011 18:09:27 UTC