- From: Cynthia Shelly <cyns@microsoft.com>
- Date: Thu, 24 May 2012 18:32:35 +0000
- To: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>
- CC: Edward O'Connor <eoconnor@apple.com>, "public-html@w3.org" <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Frank Olivier <Frank.Olivier@microsoft.com>
(re-adding public-html-a11y) Microsoft's position at the F2F was that exposing the content of a hidden referenced element *only* in the accessibility tree, without any UI, is a bad user experience. This is a different scenario than canvas. Canvas provides a drawing surface that can be linked to the sub-dom to provide a visually-rendered area for interaction on the page. A hidden element does not. There are many open issues, which haven't been explored at all. There is work needed even to understand and list all the issues with an accessibility tree that has no equivalent visually-rendered objects. Off the top of my head, I'm concerned about what happens with focusable elements in that sub-tree. How about heading navigation? What about AT other than screen-readers that assumes equivalent visual elements? I'm sure there are more issues. Building UI for displaying linked hidden content, so that it works for *all* users, not only screen-reader users, also requires a lot of thought. I know that some browsers have UI for longdesc, which might be reusable, but we're not convinced that UI provides an excellent user experience yet. We're not even sure which of these approaches will yield a better experience, and feel that a lot more work needs to be done before this is ready for a MUST requirement. We do want to leave the door open to further development on either accessibility tree or ui-based solutions, in the future, but don't feel that it's ready for a MUST requirement at this time. Personally, I'm not even sure about SHOULD, but am open to discussion on that point. However, we do want to allow the thing that works now with display:none, namely copying the flattened text into the accessible name, so that at least the text is available. I hope that clears up the confusion. --Cynthia -----Original Message----- From: Jonas Sicking [mailto:jonas@sicking.cc] Sent: Thursday, May 24, 2012 10:52 AM To: Maciej Stachowiak Cc: Edward O'Connor; public-html@w3.org Subject: Re: HTML-A11Y Task Force Consensus on Issue-204 (Updated) On Thu, May 24, 2012 at 1:20 AM, Maciej Stachowiak <mjs@apple.com> wrote: > > On May 24, 2012, at 12:54 AM, Jonas Sicking <jonas@sicking.cc> wrote: > > On Wednesday, May 23, 2012, Edward O'Connor <eoconnor@apple.com> wrote: >>> While allowing UAs to expose the accessibility tree of @hidden >>> content is great, I think we should make it a MUST level requirement. >> >> My understanding is that some AT implementors believe it would be >> difficult to comply with such a requirement. That said, I agree that >> we should encourage UAs to expose the tree to AT if they are able to. >> Would a SHOULD work for you? > > So far I haven't seen such feedback from any implementor. I've only > seen me and Maciej speak up on this and we've both said that > implementation-wise this is similar to exposing an accessibility tree > for the contents of <canvas> elements. Certainly not trivial, but > doable and something that needs to be solved in order to make canvas > accessible (which I hope we agree should be a MUST level requirement). > > However I could easily have missed other implementor feedback. If > that's the case a SHOULD level requirement might be ok. But I'd be > curious to hear how that implementor was planning on dealing with canvas. > > At the recent F2F, Microsoft representatives said that they believed > exposing full semantics for aria-describedby content would be very > hard to do in IE (in combination with the mainstream screen readers on Windows). Hard enough that they oppose a MUST requirement? Does this also mean that they oppose a MUST requirement for exposing a full accessibility tree for content inside of <canvas>? / Jonas
Received on Thursday, 24 May 2012 18:33:56 UTC