- From: John Foliot <john@foliot.ca>
- Date: Mon, 8 Dec 2014 09:04:27 -0800
- To: "'James Craig'" <jcraig@apple.com>
- Cc: "'WAI XTech'" <wai-xtech@w3.org>, "'Dominic Mazzoni'" <dmazzoni@google.com>, "'Alexander Surkov'" <surkov.alexander@gmail.com>, "'Michael[tm] Smith'" <mike@w3.org>, "'Daniel Weck'" <daniel.weck@gmail.com>, "'Ted O'Connor'" <eoconnor@apple.com>, "'Janina Sajka'" <janina@rednote.net>
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