- From: Janina Sajka <janina@rednote.net>
- Date: Wed, 10 Dec 2014 23:44:26 -0500
- To: James Craig <jcraig@apple.com>
- 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>
The ARIA-1.1 spec Introduction says the following: "User Agent Support ... "Aside from using WAI-ARIA markup to improve what is exposed to accessibility APIs, user agents behave as they would natively. Assistive technologies react to the extra information in the accessibility API as they already do for the same information on non-web content. User agents that are not assistive technologies, however, need do nothing beyond providing appropriate updates to the accessibility API. "The WAI-ARIA specification neither requires or forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities." We should probably fix the grammar in the last paragraph quoted above, i.e. should be "neither requires nor forbids." Beyond that I'm at a loss to understand how this is insufficiently clear, including for DescribedAt. Janina James Craig writes: > On Dec 10, 2014, at 1:28 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > > > > We are not in candidate recommendation stage. It is too early to state it is at risk. > > It's never too early to add an editorial note. > > > You are completely wrong that aria-describedat cannot be implemented in a device independent way. > > Have you read the editorial note in question? You seem to be under the impression that I've stated something other than what I said. > > It would be trivial (but pointless) to expose a "described at" URL to an accessibility API. This is not in question. The RFC-2119 requirements in question are: > > >> 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. > > I said, "These requirements (not aria-describedat in general, but specifically these RFC-2119 statements) are specifically *NOT IMPLEMENTABLE* in any reasonable way because:" > > 1. "They do not follow any established ARIA pattern" > > Nothing in ARIA 1.0 changes the default UI of the browser. It only changes the user agent's mapping to the accessibility API. At least four (4) implementors have commented in this thread to say this change would be problematic for a variety of reasons. You can choose to ignore those concerns if you like, but it pretty clearly indicates these statements are at risk. > > 2. and they "conflict with the defined behavior of every native host language." > > Forcing these mainstream UI requirements is specifically not implementable because it would conflict with the required behavior of every host language/technology: HTML, SVG, EPUB, etc. The languages define their own behavior. If you want this as a mainstream feature for each host language, ARIA needs to define the requirement more like it defines the requirement for "focus navigation". Note that it does not define "tabindex" as part of the ARIA spec itself. > > The "focus navigation" requirement from ARIA: > > >> 7.3 Focus Navigation > >> > >> An implementing host language MUST provide support for the author to make all interactive elements focusable, that is, any renderable or event-receiving elements. An implementing host language MUST provide a facility to allow web authors to define whether these focusable, interactive elements appear in the default tab navigation order. The tabindex attribute in HTML 5 is an example of one implementation. > > > Cite: http://rawgit.com/w3c/aria/master/aria/aria.html#host_general_focus > > Using a similar pattern, ARIA could state that, ~"An implementing host language SHOULD provide a way to link to descriptive content" or something along those lines. FWIW, any link would satisfy this requirement. > > > It is not your decision to put something at risk. It is the working groups decision. Period. > > I would agree with you if this was the formal indicator of at-risk status that you see in CR docs, but there is none. What is there is an editorial note that is dated and signed that says, the "previous paragraph may be at risk" and links to a discussion of why. It's very clearly an editorial note, and it's been there for more than six months. It's even in the previous heartbeat draft: http://www.w3.org/TR/wai-aria-1.1/#aria-describedat > > > It is inappropriate that you made a decision on behalf of the working group. We are not even remotely close to CR. > > I made no such decision. I simply stated a fact in an editorial note. It's completely appropriate. > > > Furthermore, the stake holder that requested this feature is part of PF and you initiated this discussion on a list not used for the ARIA specification and they don't even have a seat at the table. > > Janina and Michael asked me to post this to XTech because they were concerned that public-pfwg and public-html-a11y are not open lists. In contrast, anyone can join and post to XTech. > > James > -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Thursday, 11 December 2014 04:44:56 UTC