- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 1 Feb 2012 11:48:39 -0800
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: John Foliot <john@foliot.ca>, Matthew Turvey <mcturvey@gmail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On Wed, Feb 1, 2012 at 3:17 AM, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote: > On Sat, Jan 28, 2012 at 4:57 AM, John Foliot <john@foliot.ca> wrote: >> I welcome your *detailed* plans on how to deliver on the 3 key >> user-requirements previously outlined in my response to Jonas using this >> current change to the spec, your strategy on how you will convince all of >> the OSes out there to re-write their Accessibility APIs, and how you will >> further convince the hardware and software manufactures who will need to >> completely rewrite their tools to address these fundamental changes to the >> entire accessibility infrastructure. >> >> I look forward to you explaining how you can maintain html-rich content >> hidden from sighted users, maintain tab-focus of that content so that those >> non-sighted users can interact with that content, and yet how those >> additional "tabs" will not get in the way of sighted keyboard users. I will >> also remind you that AT does not simply mean screen readers, but also >> includes tools such as screen magnifiers that shift the magnification 'zone' >> to the tab-able element (and who are actively adding support for ARIA today) >> for those low-vision users who can still see the screen, but just not all of >> it. > > Regardless of what happens with @longdesc, these concerns need to be > discussed with PFWG. > > The ARIA authoring guide recommends authors use @aria-describedby to > reference descriptive sections or links to descriptions elsewhere: > > http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description > > http://www.w3.org/WAI/PF/aria-practices/#Descriptions_external > > The problems you discuss seem equally applicable to using > @aria-describedby to point to (potentially rich) tooltips as > recommended by: > > http://www.w3.org/WAI/PF/aria-practices/#Descriptions_tooltip > > The ARIA UA implementation guide says that user agents *must* expose > elements referenced by aria-describedby in the accessibility tree > regardless of hidden status: > > http://www.w3.org/WAI/PF/aria-implementation/#include_elements > > The ARIA UA implementation guide also says: > > "Note that aria-describedby may reference structured or > interactive information where users would want to be able to navigate > to different sections of content. User agents MAY provide a way for > the user to navigate to structured information referenced by > aria-describedby and assistive technology SHOULD provide such a > method." > > http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_relations_reverse_relations > > If what the ARIA guides say is not implementable (as you suggest), > that needs to be taken up with PFWG. > > If PFWG are not responsive, maybe we need to consider marking wilful > violations from ARIA in HTML5, e.g. require user agents *not* to > surface @aria-describedby content that's in @hidden DOM and throw > conformance errors when users make such references with > @aria-describedby. Cool. So it sounds like the change made my Hixie simply aligns HTML5 with the current ARIA specs. That seems like a good thing for accessibility assuming the ARIA spec was designed this way in order to create good accessibility. / Jonas
Received on Wednesday, 1 February 2012 19:49:37 UTC