W3C home > Mailing lists > Public > wai-xtech@w3.org > April 2012

Re: Alternative to @aria-describedAT: <a role=img>

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Tue, 10 Apr 2012 18:22:14 +0100
Message-ID: <CAEhSh3fPUGQ8UxfTi4QZZ62R1k35ddZ8KSVJOD+zUSPPxF_N0w@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: Alexander Surkov <surkov.alexander@gmail.com>, wai-xtech <wai-xtech@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
On Tue, Apr 10, 2012 at 5:43 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>> That's why I said that the spec denies UA to expose semantics of <a>
>> element in this case.
> I think we read it the same way. But what does "expose semantics" mean?
> Is it necessarily synonymous with "include in the accessibility tree"?

"Semantics" here clearly means more than just an accRole or xml-role
attribute in an accessibility tree. See especially the discussion in
the introduction to the spec:


User agents, user agent addons, or external AT can perform ARIA
"processing" directly on the DOM rather than through the mediation
platform accessibility APIs. For such processing to be compliant with
the spec, they must interpret the element in terms of its ARIA role
("img") not its native semantics ("a href"). Similarly, when exposing
the element to platform accessibility APIs, user agents must interpret
the element in terms of its ARIA role not its native semantics.

> WAI-ARIA 1.0 also says:
> "If an element with a role of presentation is focusable, user agents
> MUST ignore the normal effect of the role and expose the element with
> implicit native semantics, in order to ensure that the element is both
> understandable and operable."
> I am not sure what that means. E.g. if, while VoiceOver presents the
> following element,
>   <a href=link role=presentation>Long text.</a>
> the user presses the shortcut to activate the link, and the link gets
> activated, then I suppose that the user agent has ignored the "the
> normal effect" of the presentation role and instead allowed the element
> to be "operable" - but perhaps not "understandable" (since VoiceOver
> doesn't announce the link-i-ness).

(Assuming you're testing with Safari …)

The spec means Safari's behavior is incorrect. Since the element *is*
focusable, the presentation role should be dropped in favour of the
element's native semantics, and it should be exposed to the
accessibility tree (used by VoiceOver) as a link.

Benjamin Hawkes-Lewis
Received on Tuesday, 10 April 2012 17:23:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:46 UTC