W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Revert Request

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 1 Feb 2012 11:48:39 -0800
Message-ID: <CA+c2ei9oo=upsFd78YCHrPPgcbCbcD15m6XUBFbbOyhGD7yKgQ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:43 GMT