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

James Craig wrote:
>
> I have no personal issue against this and reject the implication that my 
> edits
> were somehow personally motivated. If I let personal motivations drive my 
> edits,
> I would never have added the property in the first place. I do, however, 
> have
> *technical* issues with these requirements, as I expressed to the group on 
> numerous
> occasions:

I for one am challenging these "technical" issues, while at the same time 
noting that you have said aloud and publicly, and on more than one occasion, 
that you/Apple intend to put forth a Formal Objection on this aria-attribute, 
even though the time for talking FO is far into the future. So some may be 
forgiven for drawing conclusions in advance, as it DOES appear you've already 
also pre-judged the outcome of these discussions.


> 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.

You have previously argued that this phrase "device-independent mechanism" 
somehow implies that it demands a change to the GUI, yet nothing in the 
language nor related documents I have read suggest that. You argue that ARIA 
does not, and was never intended to, change the UI. I disagree, and an 
informal "social media" poll suggests that I am not the only one who thinks 
this way.

ARIA frequently changes the UI for *non-sighted users*. Take for example the 
role of "presentation". When applied to table, it completely changes the UI 
and UX for the non-sighted user - all content inside the table is no longer 
table data, it is linearized text. As Steve Faulkner stated, "It's an 'aural 
UI' - the names, roles, states, properties & interaction instructions of HTML 
in the page, announced to the user by assistive tech".

My reading of this requirement is that the term "device-independent" reflects 
a long-standing requirement we've had that states that the 'trigger' mechanism 
(GET) for accessing the externally linked resource is device independent 
(mouse, keyboard, touch, blinking of your eyes, sipping or puffing, etc.). 
Indie UI defines it this way: "...an abstraction between physical, 
device-specific user interaction events and inferred user intent such as 
scrolling or changing values."

If my understanding of "device-independent" is incorrect in the context of 
this discussion, then at the very least might I suggest that a clear defining 
of that term be added to a Glossary? (perhaps here: 
http://www.w3.org/TR/di-gloss/)



> 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.

Rudimentarily, we can already do this today - use the browser Back 
button/feature or via <a href="javascript:window.history.back(-1);">Back</a> 
(both actions BTW already "device-independent" per my understanding of that 
term)... I am having a hard time understanding why this would be considered an 
"at risk" issue.


> 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.

As Rich notes, anything with an RFC 2119 MAY is intended simply as a 
suggestion, and no-one is required to take this suggestion or hint as anything 
more than that. (I personally think this is a reasonable suggestion BTW, but 
fall short of suggesting that it should be anything more than a MAY.)


> These requirements are specifically *NOT IMPLEMENTABLE* in any reasonable 
> way because
> they do not follow any established ARIA pattern,

We've never done something before, ergo we should never do it? I personally 
find that a weak argument, as before we had ARIA, we never had a means to 
attach semantic interaction information to dynamic web content. That didn't 
stop anyone from starting on ARIA...


> and conflict with the defined behavior
> of every native host language.

I strongly disagree.

aria-describedat is essentially nothing more than a semantically-special means 
of linking an external resource to an in-page asset. This is one of the 
earliest and most fundamental actions/interactions of the web; it is in effect 
a special anchor tag that points to a URL, and accessing that linked content 
via end-user demand is one of the earliest defined behaviors of the web we 
have - in fact I would go so far as to suggest it is one of THE *defining 
behaviors* of the web. The draft spec does not specify how the end user 
"triggers" the request for the linked asset, but only states that it must be 
device-independent. I maintain that is in keeping with previous requirements 
elsewhere within WAI.

The advantages of the aria-attribute approach are that a) it is a direct, 
programmatically defined link to its parent, and b) unlike many of the 
alternate suggestions argued during the @longdesc debate, adding the attribute 
would result in NO VISUAL INCUMBERANCE TO THE GUI. Authors do not need to 
provide a "d-link" [sic] on screen, they do not need to include the longer 
description on the same page as the complex asset requiring the description, 
solutions such as <details> and <figcaption> mandate an onscreen visual change 
to the design, etc. While these are/were all arguments in favor of @longdesc, 
they apply equally to aria-describedat as well.

Note, I will continue to advocate that when native host language alternatives 
that deliver on the same functionality exist, and _have appropriate support_, 
that they be used instead of the aria-attribute. I think most can agree that 
this is both logical and appropriate. However, for host languages that lack 
this feature, providing a means to achieve it via ARIA is the responsible 
thing to be doing.

> The requirements are at-risk, so they are marked as
> at-risk. It would be inappropriate if I did *not* note the at-risk status.

It was correct to note that they are marked as at-risk; I am questioning why 
they are currently marked as such, and fear that it may be because the 
difference between UI and GUI, and whether or not ARIA "changes the UI" is 
getting in the way of the discussion.

JF

Received on Wednesday, 10 December 2014 23:16:53 UTC