- From: John Foliot <john@foliot.ca>
- Date: Fri, 5 Dec 2014 17:16:03 -0800
- To: "'James Craig'" <jcraig@apple.com>, "'WAI XTech'" <wai-xtech@w3.org>, "'Dominic Mazzoni'" <dmazzoni@google.com>, "'Alexander Surkov'" <surkov.alexander@gmail.com>
- Cc: "'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: > > > 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