- From: John Foliot <john@foliot.ca>
- Date: Thu, 11 Dec 2014 15:44:39 -0800
- To: "'James Craig'" <jcraig@apple.com>, "'Janina Sajka'" <janina@rednote.net>
- Cc: "'Richard Schwerdtfeger'" <schwer@us.ibm.com>, "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>, "'Dominic Mazzoni'" <dmazzoni@google.com>, "'Ted O'Connor'" <eoconnor@apple.com>, "'David \(Standards\) Singer'" <singer@apple.com>, "'WAI XTech'" <wai-xtech@w3.org>, "'Alexander Surkov'" <surkov.alexander@gmail.com>, "'David Bolter'" <dbolter@mozilla.com>
James Craig wrote: > > > > > I'm open to proposals as to how best to do this, and I will take some > > time to see if I have notions on how to do it. > > > > Perhaps some additional language were we discuss our reliance on > > RFC2119 would help. But, let's do what we must to make it very clear. > > > > James, would this kind of clarification work for you? > > I see no ambiguity in the statement above, and cannot think of any > acceptable re-wording that would allow for an RFC-2119 SHOULD. > > If you want to change these statements from SHOULD to MAY, that would > suffice, as it would effectively make them no longer requirements. > MAY/OPTIONAL recommendations are in line in the prose above. UI > requirements including "UAs SHOULD" are not. James, I've already raised this previously, but to date you've not responded. I am quite concerned that you are conflating GUI with UI, and User Agent with Browser, and in both cases I believe that is part of the sticking point. Anything that exposes a link to a User Agent "that directly supports ARIA" (and more precisely this aria attribute) MUST (never mind should) provide a trigger mechanism to activate that link, and the triggering of that link MUST be device independent to be fully accessible. (HTML5 reference: http://www.w3.org/TR/html5/dom.html#interactive-content) If you are arguing to the contrary, then we have a bigger discussion on our hands. There are multiple "user agents" out there above-and-beyond "browsers", and I see absolutely nothing in the draft text that suggests "browsers" have to make changes to their GUI - or I think more importantly to the author's GUI design (I personally don't think this precludes GUI-based user-agents from making changes to their chrome - and they do that all the time already, as new features are added. Firefox just rolled out Hello Firefox, and added a new button to the chrome this week. Both Firefox and Chrome expose @longdesc in the context menu, which most would consider an extension of the browser chrome, and not the authors GUI design). While I do not claim to speak for all, I believe that many are in accordance with this view already. Since the only way to activate the link referenced by the attribute is via a trigger mechanism, the text says that the trigger must be activation-device agnostic. Reading any other requirement into that text is simply, in my opinion, reading more into the text than is there. I have also previously stated that your assertion that ARIA is not supposed to change the UI is incorrect. ARIA currently changes the aural UI all the time, and I have previously pointed to role="presentation" when applied to <table> - the semantics and user interface/user experience/user-interaction for non-sighted users are all drastically altered when this aria attribute is supported. It makes no changes to the GUI, but huge changes to what is communicated to the AAPIs, and to the end UI for some users. There is a significant difference between GUI and UI, and in this discussion (or any discussion regarding ARIA) I believe it is important to note and remember those differences. Finally, lest there be any confusion, I agree with your assertions that ARIA should not make changes to the authors GUI (unless of course the end user invokes those changes), and if it makes it any easier, I for one would fully support adding normative text to that effect in the spec. But focusing on "device-independent" in the current draft is not the way to solve the issue (IMHO). JF
Received on Thursday, 11 December 2014 23:45:21 UTC