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

On Wed, Apr 11, 2012 at 3:24 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>> You say it "suppresses the 'normal' link announcement" (implicitly by
>> screen readers), but I don't get how that helps end-users.
>
> The goal is to create the "longdesc experience" via the the anchor
> element. Do you see @longdesc as something to use when one cannot use
> an anchor?

Yes.

> To me, the advantage of @longdesc is that that instead of taking the
> focus away from the image - like a normal link often does, it instead
> focus in on the image.

What sort of "focus" are you talking about?

How does <a> take it away? How does @role="img" give it back? Are you
basing this appraisal on how some very specific user agents happen to
represent the markup in question or on the specified semantics that
constrain the ways they could represent it?

Can you give a practical example of how shifting the focus helps
end-users consume content or services?

>>> So, when, at some point @aria-describedAT materializes, would e.g.
>>> <table aria-describedAT="link"> then be an interactive element?
>>
>> If it materializes, and if it's defined to imply interactivity, and if
>> user agents actually implement interactivity on the basis of it, then
>> I guess so.
>
> OK. aria-describedAT would not not have any effect on e.g. <span
> aria-describedat=*>. I suppose no one would "see" it. But if you did
> <span role=img aria-describedat=*>, then one would see it.

Depends what the content of the <span> is, how the <span> is styled,
and how @aria-describedat were to be defined.

>> As currently specified, the <img> element would imply an "img" role
>> and the <area> elements would each individually imply the "link" role.
>
> I agree about <area>. Not so sure about <img usemap=#name>. You can't
> wrap a link around it - it is forbidden, because it is interactive.
> And, also, it is supposed to react to CSS such as
>
>   *:link{border:1px solid blue}
>
> So, by all means, it is interactive.

I think there's a good case for ignoring "presentation" on img@usemap,
just as it's ignored on a@href. Not sure how that should be specced
however.

> And my hunch is that, because it
> is interactive, the role=img is not the most logical role.

"img" is the most relevant role, because it's an image with some
associated links.

In Gecko's implementation, a11y clients use the image to discover the links:

"A more complicated set of nsIAccessible methods which can be
overridden are GetAccFirstChild/GetAccLastChild/GetAccChildCount,
which allows for objects to define their own decendant subtrees. The
default behavior for nsIAccessible::getAccFirstChild is to instantiate
a nsDOMTreeWalker, and ask it for the first child. However,
nsImageAccessible overrides getAccFirstChild, returning the first area
of an image map if there is one, otherwise nsnull. This is necessary
because the image map areas can be in a completely different area of
the DOM from the image they apply to."

https://www.mozilla.org/access/windows/msaa-server.html#The_Implementations_Behind_IAccessible

Possibly, mapping to no role in the absence of a distinct "imgmap"
role would be better.

> Or, at least: What is then the difference between <a role=img> and <img usemap=#l>?

The first is to be processed as an "img". The second is to be
processed as an "img" with associated area links (though obviously
that needs defining in Steve's mapping guide).

>>> And what is the problem with <a role=img href>? What's the principal
>>> issue?
>>
>> Representing a link to AT as an image instead of a link seems unlikely
>> to reflect author intent.
>
> That doesn't sound like a principal issue, to me.

Avoiding such failures of communication is the point of many HTML
conformance requirements.

> They say that ARIA is like CSS.

They do?

> And so, as author, I would like to use it as freely as possible.

Maybe one of the ways it's unlike CSS is that conformance checkers
warn you when you use it in odd ways.

I think the logical implication of the argument that authors should be
free to use ARIA is that we should replace all author HTML conformance
requirements with distributed authoring guides and linters. HTML WG
effectively rejected this option in favor of trying to help authors
avoid mistakes using centralised requirements.

So if you want HTML WG to change its conformance requirements, I
suggest showing how replacing the linkiness of a link with imaginess
in ARIA processing is not unlikely to reflect author intent. For
example, you could provide realistic examples where, compared to an
ordinary image, ordinary link, or ordinary linked image, it has a
positive (or at least neutral) impact on all a11y clients (including
speech recognition, screen magnifiers, text-to-speech tools for people
with learning disabilities, automated testing, and scripted
automation, not just screenreaders) and also on visual user agents
which (as encouraged by the ARIA spec) build their UIs on the basis of
ARIA processing.

>>>>> Btw, it seems seems to me that not only VoiceOver+Safari but also Jaws
>>>>> 13 have incorrect behavior as it does not expose the link-i-ness of <a
>>>>> role=img>.
>>>>
>>>> Is that because of JAWS or because of what browsers are exposing to
>>>> the accessibility tree?
>>>
>>> I suppose it is JAWS because JAWS is known to not rely on those API.
>>
>> I think you'll find it uses both. See, for example:
>>
>> http://www.paciellogroup.com/blog/2010/10/jaws-support-for-aria/
>
> Right. I think so too. But Firefox does present <a role=presentation
> href> as a link, and so I think that in this case, it is Jaws.

Do you mean it exposes it as a link in the MSAA tree?

> E.g., if I got it right, then IE presents <a role=presentation
> href> as *not* a link.

Does it?

--
Benjamin Hawkes-Lewis

Received on Wednesday, 11 April 2012 10:09:54 UTC