- From: David Bolter <david.bolter@gmail.com>
- Date: Mon, 17 May 2010 13:45:59 -0400
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- CC: Frank Olivier <franko@microsoft.com>, Cynthia Shelly <cyns@microsoft.com>, "janina@rednote.net" <janina@rednote.net>, "mike@w3.org" <mike@w3.org>, "mjs@apple.com" <mjs@apple.com>, Canvas API <public-canvas-api@w3.org>, "public-canvas-api-request@w3.org" <public-canvas-api-request@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, "surkov.alexander@gmail.com" <surkov.alexander@gmail.com>
Hi Rich, Thanks for driving this -- I know it has been a slog as we are all busy (and perhaps unsure of the right solution). Just a few comments/questions inline: On 17/05/10 9:54 AM, Richard Schwerdtfeger wrote: > Thank you for the quick response Frank. I have fixed the typo. > > David, Alex, Does the accessibility API mapping and this approach work > for you? I don't see any show stoppers but we haven't dug into implementation. The main concerns I have is actual browser implementation and author adoption. > Since Frank's mappings make use of MSAA, which you use with IA2, > it should work fine. > I'm not sure what the 'mappings' refer to? Franks' implementation notes regarding caretBlinkRate and setCaretSelection make sense to me. Did you catch Alexander's questions from May 12th? cheers, David > Maciej, will these 2D Context API changes work for Apple? I tried to make > sure that the API changes would support selection tracking on Macs. If you > could respond I would appreciate it. I sent the first draft of this to > Apple on April 11 and received no feedback. Since then the changes have > been editorial. I am doing my best to not have accessibility be a barrier > to HTML 5 getting through last call. > > At this point the NoNav attribute for the<canvas> element has passed > through the accessibility tools task force. The combination of this change > with nonav should address canvas accessibility. Charles has a change to > canvas that would allow an image map to be used as the accessible fallback > content for<canvas>. For many instances this may be easier than nonav. > Either scenario would require this proposal. > > Best regards, > > Rich > > Rich Schwerdtfeger > CTO Accessibility Software Group > > > > Frank Olivier<franko@microsoft.com> > Sent by: public-canvas-api-request@w3.org > 05/11/2010 01:48 PM > > To > Richard Schwerdtfeger/Austin/IBM@IBMUS, "david.bolter@gmail.com" > <david.bolter@gmail.com>, "surkov.alexander@gmail.com" > <surkov.alexander@gmail.com>, "janina@rednote.net"<janina@rednote.net>, > "mike@w3.org"<mike@w3.org>, "mjs@apple.com"<mjs@apple.com>, Canvas API > <public-canvas-api@w3.org>, "public-canvas-api-request@w3.org" > <public-canvas-api-request@w3.org>, HTML Accessibility Task Force > <public-html-a11y@w3.org>, "'Maciej Stachowiak'"<mjs@apple.com>, "Cynthia > Shelly"<cyns@microsoft.com> > cc > > Subject > RE: HTML Canvas 2D Context API change proposal for magnifier focus and > caret/selection tracking > > > > > > > > .caretBlinkRate() can be wired up to GetCaretBlinkTime in Windows. See > http://msdn.microsoft.com/en-us/library/ms648401(VS.85).aspx > .setCaretSelection can be wired up to SetCaretPos; MSDN has some good > documentation on this. > SetFocus() http://msdn.microsoft.com/en-us/library/ms646312(VS.85).aspx > can be used for focus management for .drawFocusRing; one approach would be > to use a child window at the x,y coordinates. > > Typo:>/p> in the setCaretSelectionPos(element, x, y) steps section. > > From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] > Sent: Monday, May 10, 2010 1:43 PM > To: david.bolter@gmail.com; surkov.alexander@gmail.com; Frank Olivier; > janina@rednote.net; mike@w3.org; mjs@apple.com; Canvas API; > public-canvas-api-request@w3.org; HTML Accessibility Task Force; 'Maciej > Stachowiak'; Cynthia Shelly > Subject: Re: HTML Canvas 2D Context API change proposal for magnifier > focus and caret/selection tracking > > I would like to have all user agent developers to please provide > feedback/changes they would like to see made to the proposal by Monday so > that I may make any necessary changes to the final draft for May 24, 2010 > to submit for a straw pole vote on May 27 in the HTML accessibility task > force. > > Frank Olivier is going through the proposal with a fine tooth comb and > will submit feedback on Thursday in terms of how these changes will map to > the Windows accessibility API. These simple changes can all be made in > MSAA as I see it so they will also be applicable to Firefox. That said, I > would like both David and Alex to review the comments from Frank and > submit them to the list. There seems to be a gap on Linux that we may need > to fill. I am not aware of an ATK API to have a magnifier track the caret > screen position. This may need to be added. > > As for Apple I would ask Maciej to look the changes and say if it can be > mapped in some way to the Mac OSX accessibility protocol either now or in > the future and if there are any changes that need to be made to the > proposal. I plan on wrapping this up next week. > > Frank indicated that the HTML working group may wish to tweak the API or > API parameter names. Personally, that is not an issue for me as long as > they are well documented which given the feedback I have as of today the > changes made the API modifications clearer. Changes reside between<ZZ> > and</ZZ> > > I know the HTML working group would like to wrap this all up quickly so I > urge you all to review and provide feedback in the requested time frame. > Here is the proposal with the attached changes in HTML format: > > http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0021.html > > There will be no Canvas Accessibility API meeting on Monday, May 17, 2010 > as I am traveling but I will have access to email and look forward to your > feedback. > > Best Regards, > Rich > > > Rich Schwerdtfeger > CTO Accessibility Software Group > >
Received on Monday, 17 May 2010 17:46:39 UTC