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

Stefan,

We don't prohibit a user agent from using WAI-ARIA features to enhance the
visual user experience. I do agree that exposing some of this information
to all users would be a real curb cut. However, I do think host language
providers can make that determination. In fact, user agents may find more
innovative ways to render the information for their advantage.

The group has done a fine job at bringing WAI-ARIA to a level where the
benefits of accessibility technology can be more readily seen for a broader
range of uses much like VoiceOver is now being used for people who want
their mail read to them when they are situationally disabled.

slick examples btw. :-)

Rich


Rich Schwerdtfeger



From:	"Schnabel, Stefan" <stefan.schnabel@sap.com>
To:	Janina Sajka <janina@rednote.net>, James Craig
            <jcraig@apple.com>
Cc:	Richard Schwerdtfeger/Austin/IBM@IBMUS, 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>
Date:	12/11/2014 02:13 AM
Subject:	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/