Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

Dear Leif Halvard Silli:

Thank you for your comments on the 16 September 2010 Last Call Working
Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2010/WD-wai-aria-20100916/). The Protocols and
Formats Working Group has reviewed all comments received on the draft. We
would like to know whether we have understood your comments correctly and
whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to us
by 9 December 2010 to say whether you accept them or to discuss additional
concerns you have with our response. If we do not hear from you by that
date, we will mark your comment as "no response" and close it. If you need
more time to consider your acknowledgement, please let us know. You can
respond in the following ways:

* If you have a W3C account, we request that you respond online at
http://www.w3.org/WAI/PF/comments/acknowledge?document_version_id=9;

* Else, by email to public-pfwg-comments@w3.org (be sure to reference our
comment ID so we can track your response). Note that this list is publicly
archived.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the archived
copy of your original comment on
http://lists.w3.org/Archives/Public/public-pfwg-comments/, and may also
include links to the relevant changes in the Accessible Rich Internet
Applications (WAI-ARIA) 1.0 editors' draft at
http://www.w3.org/WAI/PF/aria/20101202/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to 3.3.2 of
the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-pfwg-comments@w3.org. Formal objections will be reviewed during
the candidate recommendation transition meeting with the W3C Director,
unless we can come to agreement with you on a resolution in advance of the
meeting.

Thank you for your time reviewing and sending comments. Though we cannot
always do exactly what each commenter requests, all of the comments are
valuable to the development of Accessible Rich Internet Applications
(WAI-ARIA) 1.0.

Regards,

Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact


Comment 335: @longdesc implemented as ARIA construct
Date: 2010-09-15
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0053.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - img (role) <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#img>
Status: Alternate action taken

-------------
Your comment:
-------------
I hereby formally propose that role="img" permits a long description  link
inside. That is: there should be some way to make sure that a long 
description link inside a role="img" element, is presented to AT users  as
a link.

One motiviation for this request is to allow @longdesc be implemented  as
a normal link. And I hope ARIA will explain how AT which already  support
@longdesc should treat @longdesc when they see a parallel long  description
link. (They should probably ignore the @longdesc and use  the long
description link instead.)

Currently, ARIA requires AT to treat children of role="img" elements as 
presentational. And, even if you point to a link inside the role="img" 
elment via aria-labelledby, the link is only presented as a text  string,
without link features.

The method I would propose is that the first link with a rel="longdesc" 
or aria-longdesc="true" attribute inside the role="img" element, is 
treated as a long description link and presented to the user user as a 
link.

This idea was first described in the following letters, which I  recommend
to read for more detail:

http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0030
http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0031
http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0429
http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0033

--------------------------------
Response from the Working Group:
--------------------------------
ARIA today supports an aria-describedby by property intended for longer
descriptions. The reason for this is platform accessibility APIs support
short names (labels), descriptions descriptions, and relationships to long
descriptions. Today, aria-describedby supports an id value as it was
intended that the description relationship reference prose on the page that
would also be readily available to users with cognitive impairments. Rather
than introduce another attribute for longdesc the group has agreed to
consider extending aria-describedby to also support a URL. We have opened
ISSUE-411 to track this. If longdesc is removed from HTML 5 we will push
for a fast track ARIA specification enhancement that expands
aria-describedby to support this new feature. 

----------------------------------------------------------------------


Comment 336: Give @alt is not given due consideration in ARIA
Date: 2010-09-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0055.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#namecalculation>
Status: Alternate action taken

-------------
Your comment:
-------------
These are some comments to the status of @alt inside ARIA 1.0 as per 31  of
Agust 2010's working draft,  http://www.w3.org/WAI/PF/aria/complete

Please *do* read my message to wai-xtech as well:
http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0018 I will not
repeat all that is said there, here.

I will however rephrase the summary of that letter, as follows (mostly 
identical). Please note that my main focus is on how @aria-label, 
@aria-labelledby and @alt works on the <img> element. Howeer, as I  wrote
al this, I also tested role="img" on other elements, so it is not  without
relevance for other elements than <img>.

1) GENERAL. @alt is under-mentioned and under-specced in ARIA. The 
underspecification of @alt has lead to differing  implementations. Bad  for
authors and users! Examples if the lack of attention to @alt: 

	#namecalculation Section 5.2.7 on the accessible name calculation
algorithm  mentions  many attributes as example of "author" values -
amongst them it  mentions HTML @title, @aria-label and @aria-labelledby.
But it does  *not* mention @alt, which is the most important author
provided content  of HTML4 ...
  	#aria-label Likewise, when it comes to the definition of @aria-label,
then @title  is mentioned as its HTML parallel. Does that mean that
@aria-label is  not need in HTML, since it has @title? Isn't @alt a more
natural  parallel?
  	#textalternativecomputation Going back to the section 5.2.7, then
@title is only mentioned at step  2D, after the text node content has been
considered. How can  @aria-label, with it high priority, be considered
similar to the low  priority @title attribute? Please rather compare
aria-label with @alt.
 	#textalternativecomputation @alt is mentioned under the last list item
of step 2A, and the text  says that aria-labelledby if present should have
highest priority, then  comes aria-label if present and finally @alt if
present. In practise,  for <img>, then ARIA supporting ATs first considers
the role of  element.

In most AT, the default role of <img> is affected not only by the 
presence of @role but also of whether @alt is empty or none empty.
  	* Thus, in practise, many AT consider if @alt is empty or non-empty 
first,
  	* if non-empty then they prioritize aria-label - if present, else they 
prioritize @alt's content.  	* If @alt was emtpy, then they may not
consider whether @aria-label  nor @aria-labelledby (AT differ on this)
 	* but if @role="img" is present and alt is empty, *then* and only do 
they look at @aria-labelledby Thus, it is all very convoluted.

2) What is supposed to happen if aria-labelledby points to an element 
whose only content is located inside @alt, @title or @aria-label?    AT
differ in what they do: OSX10.5's VoiceOver and Jaws11+Firefox  consider
@alt as the content, Jaws12+Firefox consider aria-label as the  content,
NVDA consider both. I don't see where in the spec this  explained. (I think
most authors will expect that aria-label points to  an element whose text
node contetn will be used.) It is clear that  author provided values, such
as aria-labelledby, has priority over the  element's own content text node.
The question is what if  @aria-labelledby points to an element whose
content author content  only, or a mix of author content and text node
content?

3) ATs generally give @alt higher priority than ARIA says, and most of 
them ignore @labelledby if @alt is non-empty.

4) For <img>, then ATs in practise links a double meaning to the empty 
@alt: aria-labelledby generally only work as expected when the @alt is  the
empty string. At the same time HTML5 says that empty @alt means 
role="presentation".

5) A consequence of the fact that aria-labelledby is ignored when @alt  is
non-empty (see 3) and 4) above)  is that it is impossible to get an 
aria-labbelledby which points to <img> itself (<img id=A alt=FOO 
aria-labelledby="A B">) to work, despite that ARIA says it should work. 
(This might work better for <div role="img"> tha for <img role="img"> - 
please check.)

6) The algorithm doesn't say what role it plays that the @alt is or  isn't
the empty string. Which is just an example of how ARIA doesn't  incorporate
the semantics @alt. But while ARIA doesn't take it in, it  is clear that AT
in various degrees take it in. E.g consider the  convoluted way AT
prioritize between @alt, @aria-label and  @aria-labelledby. (I don't claim
that AT do it correct and tha ARIA do  it wrong - proably both AT and ARIA
need fixing ...)

A really important point to me is that AT should see the @alt as the 
content of <img>. Perhaps ARIA should consider @alt more like text node 
content than author content? Or, when I think about it: perhaps, that  is
what you do - and perhaps that's the problem! Because, for other  elements,
it doesn't matter for the element's semantics whether it is  empty or
non-empty. Whereas for <img>, the <img alt=""> and <img  alt="non-empty">
are considered different beasts. 

Sorry, a convoluted response to a convoluted problem. 

--------------------------------
Response from the Working Group:
--------------------------------
We have modified section 5.2.7 to bullet 1. "values" to include the alt
attribute such that it is on par with aria labeling. Thank you for
identifying this omission. You should note, however, that alt is referenced
in bullet 2A in the name computation putting it on equal footing with aria.


To address your question regarding equivalence between aria-label and
title, title is not equivalent as user agents use the title attribute to
generate tool tips during a hover. This is not the behavior desired in most
rich internet applications. For example, you would not want a menuitem in a
menu to generate a tooltip. You would also not want to have to use a
labelledby relationship in all instances as it requires a separate element
reference to the label. It is for these use cases that we have aria-label
to be used to fulfill the accessible name computation in accessibility API
supported by user agents. Certainly, if you have an image with an alt
attribute the accessible name can be computed by the alt text. The name
computation does not preclude this. 

We would like to point out that the specification does not place title at
a higher priority or on parallel with aria-label and aria-labelledby. In
fact, in section 2A under name computation it recommends the use of @alt
when aria-label and aria-labelledby are not present. It also references the
appropriate sections in both HTML 4 and 5 for as to what is used for
alternative text. 

Consequently, we agree that @title should not be given equal rating to
@alt and @title is really the last resort for computing alt text when all
other mechanisms fail. However, we do believe the specification addresses
this.

Regarding your point about ATs preference of computing alt as a label
mechanism, we prescribe what a user agent is to do to compute the
accessible name of an element. Firefox, does compute the name with
precedence given to aria-labelledby over alt. If an AT uses the @alt
attribute, over aria-labelledby, it would need to circumvent the
accessibility mapping as defined in ARIA and may need to access the DOM
directly to get it. We have found that AT vendors often do not always
follow industry specifications and we do not control how an AT renders ARIA
content. VoiceOver reads the aria labelledby with the alt text treating
both alt and labelledby equally. JAWS incorrectly reads the alt text and
ignores the labelledby reference. We have raised this issue with Freedom
Scientific and they agreed this is a problem. ATK and IAccessible2 provide
an aria-labelledby relationship. In that instance the alt text is stored in
the accessible name and the label is referenced in the relationship. The
implementation varies based on the accessibility API used and the AT. Our
specification does not state how an assistive technology is to process an
accessibility.

Received on Thursday, 2 December 2010 22:26:50 UTC