RE: Is ARIA A11y only? [Was: @aria-describedat at-risk ...]

Can of worms opened.

What about exposing other properties, such as "aria-label" visually in user agents? 
Imagine someone labels a span with a CSS font image using "aria-label" which is perfectly valid as alternative to alt (because there is NO alt support for span):

<span role="img" class="bgimage" aria-label="Save" onclick="doSomething()">(CSS vector symbol font char)</span>

And don't say this is an authoring error. This is common practice since using vector fonts grant scalability of images. ARIA is a blessing here for identification.

Sure, you can use title attribute here but this is redundant and chances are that not all AT will check that (since title on span is considered still as "exotic"):

<span role="img" class="bgimage" aria-label="Save" title="Save" onclick="doSomething()">(CSS font char)</span>

But what you do on mobile devices that do not support tooltips? 

I understand that exposing ARIA props visually in UA's has been intentionally omitted in ARIA 1.0 but sooner or later time will tell if this was a good decision.
Anyway, James is striving for a holistic approach - always a good thing.
For now I think we need an entire separate new spec for that - IF there should be a spec.

- Stefan

-----Original Message-----
From: Janina Sajka [mailto:janina@rednote.net] 
Sent: Donnerstag, 11. Dezember 2014 05:44
To: James Craig
Cc: Richard Schwerdtfeger; W3C WAI Protocols & Formats; Dominic Mazzoni; Ted O'Connor; David (Standards) Singer; WAI XTech
Subject: Re: Is ARIA A11y only? [Was: @aria-describedat at-risk ...]

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 08:13:08 UTC