- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 14 Sep 2010 07:01:31 +0200
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: wai-xtech@w3.org
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:11 UTC