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

James,

As I have stated, nothing forces the mainstream UI to do anything. There is
nothing in there that is a MUST RFC requirement. You know that SHOULD or
MAY statements (and we have a number of these) do not require user agents
to conform to these statements. It is merely a suggestion. In previous
posts on this subject I have stated that decision to implement any UI
feature should be the job of the host language and not the WAI-ARIA spec.
There is nothing in that statement that would require a test procedure to
validate that functionality to pass Candidate Recommendation. The only
thing that we would need to do is verify the accessibility API mapping.
That is the intent of the WAI-ARIA spec.

What is important is that ARIA would provide a vehicle to get access to
that additional information by the user agent should that feature be
accepted by the group.

Rich



Rich Schwerdtfeger



From:	James Craig <jcraig@apple.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	W3C WAI Protocols & Formats <public-pfwg@w3.org>, Dominic
            Mazzoni <dmazzoni@google.com>, "Ted O'Connor"
            <eoconnor@apple.com>, Janina Sajka <janina@rednote.net>, "David
            (Standards) Singer" <singer@apple.com>, WAI XTech
            <wai-xtech@w3.org>
Date:	12/10/2014 07:58 PM
Subject:	Re: Is ARIA A11y only? [Was: @aria-describedat at-risk ...]



On Dec 10, 2014, at 1:28 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
>
> We are not in candidate recommendation stage. It is too early to state it
is at risk.

It's never too early to add an editorial note.

> You are completely wrong that aria-describedat cannot be implemented in a
device independent way.

Have you read the editorial note in question? You seem to be under the
impression that I've stated something other than what I said.

It would be trivial (but pointless) to expose a "described at" URL to an
accessibility API. This is not in question. The RFC-2119 requirements in
question are:

>> 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. For example, a user
agent may provide access to the document or document fragment referenced by
the aria-describedat attribute in a contextual menu associated with the
object.

I said, "These requirements (not aria-describedat in general, but
specifically these RFC-2119 statements) are specifically *NOT
IMPLEMENTABLE* in any reasonable way because:"

1. "They do not follow any established ARIA pattern"

Nothing in ARIA 1.0 changes the default UI of the browser. It only changes
the user agent's mapping to the accessibility API. At least four (4)
implementors have commented in this thread to say this change would be
problematic for a variety of reasons. You can choose to ignore those
concerns if you like, but it pretty clearly indicates these statements are
at risk.

2. and they "conflict with the defined behavior of every native host
language."

Forcing these mainstream UI requirements is specifically not implementable
because it would conflict with the required behavior of every host
language/technology: HTML, SVG, EPUB, etc. The languages define their own
behavior. If you want this as a mainstream feature for each host language,
ARIA needs to define the requirement more like it defines the requirement
for "focus navigation". Note that it does not define "tabindex" as part of
the ARIA spec itself.

The "focus navigation" requirement from ARIA:

>> 7.3 Focus Navigation
>>
>> An implementing host language MUST provide support for the author to
make all interactive elements focusable, that is, any renderable or
event-receiving elements. An implementing host language MUST provide a
facility to allow web authors to define whether these focusable,
interactive elements appear in the default tab navigation order. The
tabindex attribute in HTML 5 is an example of one implementation.


Cite: http://rawgit.com/w3c/aria/master/aria/aria.html#host_general_focus

Using a similar pattern, ARIA could state that, ~"An implementing host
language SHOULD provide a way to link to descriptive content" or something
along those lines. FWIW, any link would satisfy this requirement.

> It is not your decision to put something at risk. It is the working
groups decision. Period.

I would agree with you if this was the formal indicator of at-risk status
that you see in CR docs, but there is none. What is there is an editorial
note that is dated and signed that says, the "previous paragraph may be at
risk" and links to a discussion of why. It's very clearly an editorial
note, and it's been there for more than six months. It's even in the
previous heartbeat draft:
http://www.w3.org/TR/wai-aria-1.1/#aria-describedat

> It is inappropriate that you made a decision on behalf of the working
group. We are not even remotely close to CR.

I made no such decision. I simply stated a fact in an editorial note. It's
completely appropriate.

> Furthermore, the stake holder that requested this feature is part of PF
and you initiated this discussion on a list not used for the ARIA
specification and they don't even have a seat at the table.

Janina and Michael asked me to post this to XTech because they were
concerned that public-pfwg and public-html-a11y are not open lists. In
contrast, anyone can join and post to XTech.

James