W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > July to September 2010

Re: Give @alt is not given due consideration in ARIA

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 17 Sep 2010 11:41:41 -0500
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, janina@rednote.net
Cc: public-pfwg-comments@w3.org, public-pfwg-comments-request@w3.org
Message-ID: <OF34023FB5.DDEB7838-ON862577A1.005A9688-862577A1.005BB4F1@us.ibm.com>

Hi Leif,

We are more than past the last call date to ARIA spec. you are referring
to. This list is for public comments for TR working drafts and not
editorial drafts. This is also not a discussion forum.

There must be a communication issue somewhere on this. Perhaps Janina can
help as to the appropriate vehicle to communicate your concerns.


Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
To:	public-pfwg-comments@w3.org
Date:	09/15/2010 07:33 PM
Subject:	Give @alt is not given due consideration in ARIA
Sent by:	public-pfwg-comments-request@w3.org



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.
--
leif halvard silli






graycol.gif
(image/gif attachment: graycol.gif)

Received on Friday, 17 September 2010 16:42:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:02 GMT