@alt in ARIA (Was: Default role of <IMG> should be "img")

Steven Faulkner, Mon, 13 Sep 2010 12:26:07 +0100:

You quoted: [1]
> "the user agent MUST NOT expose the implicit native semantics of the 
> element (the role and its states and properties)"

But @alt is not defined as 'state' or 'property' in ARIA: [2]
]] In this document, states and properties are both treated as 
aria-prefixed markup attributes. [[
  
> if <img> was like this:
> <img [role="presentation"] > alt text </img> 
> then it would work , but its not.

Indeed. And, also, had we been talking about 
  <img role="presentation" aria-label="Alt text." alt="" /> 
then it would be clear that BOTH the implicit role AND the aria-label 
string should be hidden. However, we are talking about 
  <img role="presentation" alt="Alt text."/> 
where the @alt from the host language's point of view, is content, and 
thus ought to be "MUST expose" in ARIA[1]. 

Interestingly, ARIA itself juxtaposes @aria-label to @title, [3] which 
is only an advisory attribute in HTML. And most ATs seem, in varying 
degree and against ARIAs "Accessible Name Calculation" algorithm, to 
consider the @alt as the <img>'s content, rather than treating it as a 
host language native variant of aria-label and aria-labelledby.

For example, ARIA says: When present and not empty, then 
@aria-labelledby (1st) @aria-label (2nd) has priority over @alt [inside 
the element that is to be labelled, I guess - those elements from were 
the labels are picked, is another matter].[4] 

However, for <img role=img aria-labelledby=foo alt=bar >, then both 
Jaws12+Firefox and VoiceOver/OSX10.5 use @alt and ignore @labelledby. 
(NVDA doesn't ingore it.) Jaws11 and VoiceOver-or-OSX10.5 also ignore 
aria-label(ledby) when @alt is the empty string, which seems in 
accordance with HTML5 (and also with ARIA, when one counts in that 
alt="" equals role=presentation). [But NVDA and JAWS 12 do not ignore 
@label(ledby) in that situation, and - of course - one could see 
	<img aria-labelledby=X alt="" src="*"> as equal to 
	<img aria-labelledby=X alt="" src="*" role="img" >] 

However, for <img role=img alt="" aria-labelledby=x >, then 
@aria-labelledby is used, which seems according to ARIA. But with only 
a single space character, rather than the empty string, as the @alt 
text, then VoiceOver & Jaws+FF ignore the @aria-labelledby. (Even 
Jaws12 ignores @labelledby if @alt is non-empty.) Thus, for <img 
role="img"> ATs (except NVDA) seem to use @labelledby only if @alt is 
empty - which means that they treat @aria-labelledby as "fallback" for 
@alt. 

The differences between ARIA and implementations can be summed up as 
follows:

ARIA: aria-labelledby first, EESE aria-label, OR ELSE @alt
Most ATs implement: aria-label first, ELSE @alt (if non-empty), OR ELSE 
aria-labelledby

There are probably two reasons for this why AT implements what they do: 
a) ARIA has developed a general system, and has failed to specifically 
tak @alt propertly into account. b) Most ATs simply consider the @alt 
as the very content of the element, and thus do not look at the ARIA 
attributes when @alt is non-empty.

Also note that if you have 
<!--1--> <img aria-label=Bar alt=Foo role=img >
<!--2--> <button aria-labelledby=i >
           <img aria-label=Bar alt=Foo role=presentation id=i />
         </button>
then for the first <img>, the aria-label is used (in VoiceOver and 
according to ARIA). Whereas for the button, then both Jaws and 
VoiceOver exposed the img@alt, and not the img@aria-label, as the 
content. (Even an @alt inside any other elment, such as <span alt="Foo" 
></span>, will work.) Which, again, means that @alt is considered as 
the content of <img>.  (Ooops, here is an exception: Turns out that in 
Jaws12, probaly unlike Jaws11, will use @aria-label rather than @alt 
... NVDA in same situation is able to use @alt as well as @aria-label.)

ARIA's accessible name calculation split the a11y names into two kinds 
- 'author' and 'contents': [5]
  ]]
    1. author: [...] features such as the aria-label attribute, 
                aria-labelledby attribute, or the HTML title attribute.
    2. contents: name comes from the text value of the element node. … 
  [[

Note that @alt is not mentioned! But, clearly, @alt falls into the 
author category, when the picture is painted like that. But the funny 
thing is that when an author feature, such as aria-labelledby, points 
to an <img>, then it is the author provided @alt text that is used as 
content. So, in reality, @alt is partly treated as content kind and 
partly as author kind. (Note, again, that JAWS12 looks at @aria-label 
only, and NVDA considers both @aria-label and @alt.)

Aria-describedby/-labelledby/-label are socalled global attributes, 
which explains why they can point to hidden elements. But where does 
ARIA explain that "Foo" becomes the label, if <element 
aria-labelledby="img"> points to <img id="img" alt="Foo">?

Conclusions - regarding @alt and the A11Y name calculation algorithm: 
1) @alt is underspecified in ARIA. At crucial spots in the ARIA spec, 
like in the accessible name calculation algorithm descriptoin, and in 
the definition of @aria-label, ARIA mentions @title as relevant 
example. But doesn't mention @alt. Really strange!
2) I cannot find what happens, if aria-labelledby points to an element 
whose only content is located inside @alt, @title or @aria-label. AT 
differ in what they do: some consider @alt, one consider aria-label 
only, one consder both.
3) ATs generally give @alt higher priority than ARIA says, and most of 
them ignore @labelledby if @alt is non-empty
4) 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 3) and 4) 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.
6) The algorithm doesn't say what role it plays that the @alt is or 
isn't the empty string.
7) The underspecification of @alt has lead to differing 
implementations. Bad for authors and users!
8) The regard for to the intented semantics linked to @alt in HTML5, is 
difficult to spot. 

There is no simple pattern that can help me understand how it works ... 

NOTE/PROPOSAL:
I like very well that the children of an elements whose role is "img", 
are considered presentational - that creates many opportunities! And, 
clearly, the wish is to model role="img" a bit after how <img> works - 
and <img> cannot have any children.

However, if I change <div role=img><p>foo</div> to <div 
role=presentation><p>foo</div>, then "foo" becomes visible. Whereas if 
I change <img alt="foo"> to <img role="presentation" alt="foo">, then 
"foo" disappears from AT. That to mee seems illogical and not fully in 
respect of the main host language, HTML. I wonder why ARIA has ended up 
working like that. And I propose to change it so that "foo" becomes 
visible in both cases. As documented above ARIA and ARIA supporting 
AT's implementation of @alt is nevertheless so buggy that it needs to 
be fixed.

[0] http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/0014
[1] http://www.w3.org/WAI.new/PF/aria/complete#presentation
[2] http://www.w3.org/WAI.new/PF/aria/complete#statevsprop
[3] http://www.w3.org/WAI.new/PF/aria/states_and_properties#aria-label
[4] 
http://www.w3.org/WAI.new/PF/aria/complete#textalternativecomputation
-- 
leif halvard silli

Received on Tuesday, 14 September 2010 05:02:07 UTC