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

Received on Thursday, 11 December 2014 01:57:51 UTC