W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Re: Issue 131

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 15 Sep 2011 11:09:07 -0700
Message-ID: <4E723F43.8050308@jumis.com>
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
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:32 UTC