RE: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

James Craig wrote:
>
> > Dominic wrote:
> >
> >> I have no strong opinion on supporting longdesc and/or aria-
> describedat for exclusive use by screen readers or other AT - i.e. as
> something that'd be invisible to most users.
> >>
> >> One thing I feel more strongly about: until now, everything in ARIA
> only affects how the user agent communicates with AT, it never changes
> the visual layout or the semantics of how the page works for users who
> aren't running any AT. Exposing aria-describedat in the context menu
> would be a significant departure from this. One potential concern is
> that web developers would become more suspicious of ARIA in general and
> not want to apply simple accessibility bug fixes without worrying about
> the implications for their design.
>
>
> I've expressed the same concern with aria-describedat, in addition to
> the concerns Ted listed in the formal objection to longdesc.

...and yet, Dominic himself closed the @longdesc bug in Chromium just
yesterday:
https://code.google.com/p/chromium/issues/detail?id=224285#c40

...where Chromium now exposes the longdesc value *in the context menu* (when
the plugin is installed). This also mirrors the native solution in
Mozilla/Firefox. I'll note as well that those concerns raised in Apple's
Formal Objection to @longdesc were addressed and a decision was rendered
with those concerns in mind.

Can we get a technical explanation of why this is now being considered as an
at-risk item? Putting aside personal preferences for a minute, what is the
nature of the risk? That Mozilla and Chromium might choose to expose
aria-describedat in a fashion similar to (or identical to) how they
currently handle @longdesc? Do we have any documented proof that developers
/ designers / content creators are unhappy with this compromise?

Upon examination of the Draft ARIA 1.1 Spec, I read the following:

	"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."
[JF: No explicit or implied mention of UI requirements here, outside of
"device-independent mechanism"]

	"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."
[JF: No mention of UI requirements here either, outside of
"device-independent mechanism"]

	"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."
[JF: Native behavior for @longdesc in Mozilla, now implemented by Chromium
with similar UI behavior, as well as a plethora of plugin solutions that
follow the same general paradigm.]

	JC 2014-06-03. The previous paragraph may be at-risk. Implementors
from Mozilla, Google, and Apple have expressed concern over the RFC-2119
"SHOULD" requirement above: If the statement remains as-is, aria-describedat
would break the ARIA pattern to not affect mainstream UI.
[JF: Again, I see no explicit mention of "mainstream UI" in any of the
referenced prose. What am I missing?]

	Dominic M. mentioned(*) that if this pattern changed, developers may
become more "suspicious of ARIA and not want to apply simple accessibility
bug fixes without worrying about the implications for their design." Alex S.
said, UI-based requirements "should be rather part of HTML than ARIA."
[JF: There is nothing in the referenced section that speaks to UI behavior,
beyond a "For example" statement with an RFC MAY associated to it.

(* JF: I note that this statement was made 7 months ago, and a lot has
changed since that time.)

A question to Dominic and Alexander, since they have both been singled out
as commenter's, do your respective organizations have any specific issue
with treating the "UI interaction" of aria-describedat with the same or
similar solution you have applied to @longdesc (given that the draft spec
does not specify any explicit UI requirements)? While I know that some are
still not 100% satisfied with the Chromium "plugin" requirement, I
personally have heard no complaints with moving the interaction into the
context menu.

Cheers!

JF

Received on Saturday, 6 December 2014 01:16:38 UTC