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

James Craig wrote:

> > Putting aside personal preferences for a minute, what is the nature of
> > the risk?
>
> The nature of the risk is that implementors are extremely unlikely to
> implement these 3 RFC-2119 requirements.
>
> 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.
> Cite: http://rawgit.com/w3c/aria/master/aria/aria.html#aria-describedat
>
> The PFWG voted to add a mainstream UI requirement based on an ARIA
> attribute (~UAs SHOULD, not ATs MAY) which goes against an established
> pattern and previously stated goal of ARIA. The outcome of the vote was in
> direct conflict with serious concerns from from member representatives of
> three different user agent vendors: WebKit, Blink, and Gecko.

So I see nothing in that text that mandates any form of specific UI changes; I 
think you are reading more into it then is there. It simply calls for "... a 
device-independent mechanism...", which need not have an impact on the UI 
per-se (certainly not the GUI).

Further, the concerns from Blink and Gecko... are they still concerns? As I 
noted previously, since the conversation you have quoted transpired, we now 
have native support for @longdesc in Gecko, and (hopefully) impending native 
support in Blink (per Dominic's comments), so I would very-much like to hear, 
again and specifically, from the Blink and Gecko teams if they feel that 
supporting aria-describedat in exactly the same fashion as @longdesc is either 
onerous or troubling to them (*). And while the IE team has been silent, if 
there is any feedback from that camp, I'd love to hear it.

Finally, the text notes "User Agents" and not "Browsers", which in the 
broadest context could mean that visual AT tools could end up the home for 
this requirement: we already have a precedent there, where ZoomText supports 
ARIA landmark roles when using WebFinder.
(source: http://www.aisquared.com/support/more/zoomtext_100_release_notes)

NOTE, I am not saying this is the preferred solution, only that User Agent is 
more than just Browser in W3C parlance (and AT is more than just Screen 
Reader).

(* Dominic has responded - 12/5/14 - by stating:
	"I'm perfectly happy with exposing aria-describedat to AT via accessibility 
APIs. Unlike with longdesc, I don't like the idea of exposing aria-describedat 
in the context menu by default. The reason is that up until now, ARIA does not 
change the behavior of the user agent at all. It simply passes additional 
information to AT. The browser doesn't render anything differently, respond to 
events differently, or anything else like that. Suggesting that the browser 
directly expose aria-describedat to all users would totally change that, and I 
worry it would set a bad precedent."
http://lists.w3.org/Archives/Public/wai-xtech/2014Dec/0006.html)


> I should note that the vote happened on a phone call where I was the
> primary dissenter. The other who expressed concern were not present on the
> phone call and the vote was not extended to the email list.

I think as well that your characterization of "dissent" w.r.t. Gecko and Blink 
is, shall I say, somewhat exaggerated, but (again) I think we should ask these 
actors directly, and neither you nor I assume anything.

Dominic's comment stated "...potential concern..." (not open dissent), and 
Alex said, "...not clear whether the attribute should be mapped to 
accessibility API or the browser have to have some UI for that [3]. It'd be 
good to make it clear because if UI is an option here there then I would say 
"aria-describedat" should be rather part of HTML than ARIA." (again, I read 
that as a preference, but not necessarily as strong "dissent").

Question for Alex: do you believe that native HTML accessibility support 
constructs should be available to all markup languages? That ARIA is, by 
design, markup language agnostic and so if an accessibility feature is 
available in HTML, it should also be abstracted and available to other markup 
languages via ARIA?

JF

Received on Monday, 8 December 2014 17:05:06 UTC