W3C home > Mailing lists > Public > public-pfwg@w3.org > December 2014

Re: Is ARIA A11y only? [Was: @aria-describedat at-risk ...]

From: James Craig <jcraig@apple.com>
Date: Thu, 11 Dec 2014 14:22:50 -0800
Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>, Dominic Mazzoni <dmazzoni@google.com>, Ted O'Connor <eoconnor@apple.com>, "David (Standards) Singer" <singer@apple.com>, WAI XTech <wai-xtech@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>, David Bolter <dbolter@mozilla.com>
Message-Id: <168B42DE-ABE1-4F92-A468-1D7C07B2A24C@apple.com>
To: Janina Sajka <janina@rednote.net>

> On Dec 11, 2014, at 12:44 PM, Janina Sajka <janina@rednote.net> wrote:
>>> Beyond that I'm at a loss to understand how this is
>>> insufficiently clear, including for DescribedAt.
>> It is clear, but it is clearly in direct conflict with the new UA reqs in
>> #aria-describedat.
>>>> The WAI-ARIA specification neither requires or forbids user agents from
>>>> enhancing native presentation and interaction behaviors on the basis of
>>>> WAI-ARIA markup. [1]
>> And then later, a direct contradiction in #aria-describedat:
>>>> User agents SHOULD provide a device-independent mechanism to allow a
>>>> user to navigate the user agent to content referenced by the aria-
>>>> describedat attribute. User agents SHOULD also provide a device-
>>>> independent mechanism to return the user's focus from the descriptive
>>>> content view to the original content view. [2]
> Where you see two statements in conflict, I see the first statement
> defining the bounds of the second.
> If we haven't made that sufficiently clear, then we need to clarify that
> somehow, and we should do so globally, to avoid exactly this kind of
> confusion.
> I'm open to proposals as to how best to do this, and I will take some
> time to see if I have notions on how to do it.
> Perhaps some additional language were we discuss our reliance on RFC2119
> would help. But, let's do what we must to make it very clear.
> James, would this kind of clarification work for you?

I see no ambiguity in the statement above, and cannot think of any acceptable re-wording that would allow for an RFC-2119 SHOULD.

If you want to change these statements from SHOULD to MAY, that would suffice, as it would effectively make them no longer requirements. MAY/OPTIONAL recommendations are in line in the prose above. UI requirements including "UAs SHOULD" are not.

Received on Thursday, 11 December 2014 22:23:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:16 UTC