- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Wed, 1 Feb 2012 11:17:11 +0000
- To: John Foliot <john@foliot.ca>
- Cc: 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 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.
--
Benjamin Hawkes-Lewis
Received on Wednesday, 1 February 2012 11:17:49 UTC