- From: Paul Cotton <Paul.Cotton@microsoft.com>
- Date: Thu, 5 Jul 2012 15:23:37 +0000
- To: Edward O'Connor <eoconnor@apple.com>, Frank Olivier <Frank.Olivier@microsoft.com>
- CC: "public-html@w3.org" <public-html@w3.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
- Message-ID: <AB5704B0EEC35B4691114DC04366B37FBE1774@TK5EX14MBXC289.redmond.corp.microsoft.co>
Ted, Frank: Can we get an estimate of when you will be able to answer these questions? /paulc HTML WG co-chair Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 From: Steve Faulkner [mailto:faulkner.steve@gmail.com] Sent: Saturday, June 30, 2012 2:47 AM To: Edward O'Connor; Frank Olivier Cc: public-html@w3.org; Richard Schwerdtfeger; HTML Accessibility Task Force Subject: Re: ISSUE-201: Aligning the two change proposals Hi ted, I consider the rationale and details for the lightweight hit regions to be insufficient your CP states: "The proposed addHitRegion()method allows for tying hit regions to either elements or to lightweight objects which simply provide a label and a WAI-ARIA role. This helps authors to make their canvas content accessible without incurring an unacceptable performance penalty." Your CP defines 'lightweight' hit regions without: a) the ability to make them focusable b) the ability to add accessibility states and properties that are associated with interactive objects. Only providing the ability to add a role to lightweight regions means the the usable ARIA roles is limited to a subset of non widget roles, and even then those roles usefulness ir constrained as they cannot have ANY states and properties assigned. It would be helpful for reaching consensus on this if you could: a) detail in your CP why the above are not required, or b) add the ability to make the lightweight regions focusable and provide he ability to associate the required states and properties, or c) drop the lightweight hit regions from your CP regards SteveF On 29 June 2012 23:03, Edward O'Connor <eoconnor@apple.com<mailto:eoconnor@apple.com>> wrote: Hi all, I wrote: > Frank and I got together today and went through the remaining > ISSUE-201 items. I've made a pass at updating my Change Proposal to reflect what came out of that meeting. The updated proposal is available here: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-201 Please review this updated proposal and let me know if I missed anything. Here's the diff from the previous version of the proposal: http://www.w3.org/html/wg/wiki/index.php?title=User%3AEoconnor%2FISSUE-201&diff=13191&oldid=12969 >> [Frank's CP only] A method ( clearElementPath() ) to remove hit >> regions. I think we should have this in the joint proposal, as relying >> on ClearRect or other drawing mechanisms to clear an association seems >> overly involved and a burden on the author. > > We both agreed that having a clearElementPath() method makes sense. To keep the method names aligned, I've added removeHitRegion() to my proposal. >> r7025 - Add ellipse support to canvas. not needed, not accessibility > Agreed; can wait. > >> r7026 - Add SVG paths to Path objects in canvas. > Agreed, can wait. I removed these revisions from the list of revisions to restore. >> r7028 - add dashed lines and change how Path objects work to instead >> use external line and font styles and transformation objects > > I need to look at this in more detail to see if the refactoring is > necessary to make Path sufficiently useful. I think leaving this in is probably necessary to keep the Path definition sane. >> r7033 - More font metrics. > Definitely helps wit hit testing runs of text, so I'd prefer to keep > this in. That said, I can live with putting it off until HTML.next. > >> r7034 - Path copy constructor > I don't see the harm in keeping it, but like the font metrics, I can > live with putting it off as well. I removed these revisions from the list of revisions to restore. Rich wrote, in <OF2EA82CD1.735CE9CF-ON86257A2A.006A8BD4-86257A2A.006ADC8C@us.ibm.com<mailto:OF2EA82CD1.735CE9CF-ON86257A2A.006A8BD4-86257A2A.006ADC8C@us.ibm.com>>: > Does this mean that the ligtweight JSON objects will be an html.next > discussion item? Sorry, I failed to mention unbacked region descriptions in my summary email of the conversation I had with Frank. I argued for keeping them in this version of the feature. I think Frank could live with that, but I don't want to put words in his mouth. Frank, what do you think? I haven't changed this aspect of my proposal. Ted -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com<http://www.paciellogroup.com> | www.HTML5accessibility.com<http://www.HTML5accessibility.com> | www.twitter.com/stevefaulkner<http://www.twitter.com/stevefaulkner> HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/<http://dev.w3.org/html5/alt-techniques/> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html <http://www.paciellogroup.com/resources/wat-ie-about.html>
Received on Thursday, 5 July 2012 15:24:25 UTC