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

Benjamin Hawkes-Lewis, Wed, 11 Apr 2012 11:09:03 +0100:
> On Wed, Apr 11, 2012 at 3:24 AM, Leif Halvard Silli 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.

I meant "something to use *only* when on cannot use an anchor".

>> 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?

As in "deeper look/analysis". Also, @longdesc is supposed to let you 
read the image description and thereafter, to be back at the same 
location (where the original image is located) on the page. Thus, 
longdesc does two things: It allows reader to take a deeper - and 
probably textual -  look at the image *and* it allows the user to, 
after the deeper look, be back at the same location in the original 
page. See Laura's prop.

> How does <a> take it away?

It is more about what positive @longdesc does than about something 
negative with <a>. 

> How does @role="img" give it back?

It doesn't - not alone. Well, it is a start, and I've said it earlier 
in this thread: One reacts differently to "this is a link" from how one 
reacts to "this is an image". 

> 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?

I may not understand what you imply - or ask. But the task I have given 
myself is: "I want to use longdesc, but not every UA support it." If 
you read the blog post that I mentioned in the initial message, then 
you'll see that I created something that works in every browser and 
every AT.

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

See above. Also, see the CNN front page example I mentioned for 
Alexander.

>>>> 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.

My reason to assume that aria-describedat inside <span 
aria-describedat=l><img></span> would hardly have any effect, is that 
ARIA says that properties and states are not made use of when the 
element's role is (equivalent) to presentational.

So aria-describedat - unlike an anchor - is not something that, alone, 
makes the element focusable. I think. But of course: They have to spec 
aria-describedAT first.

>>> 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,

Upon reflection: I would agree if you had said "good case to default to 
role=img".

> 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 practice, the image of an image map often don't have an @alt, and 
UAs vary a great deal with regard to whether the image and the alt is 
presented at all. Hey, they even vary with regard to whether the @alt 
of <area> is presented to AT. (E.g. VoiceOver don't.)

> 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.

Possibly. Side note: Firefox, since version 4, has had a quite buggy 
image map implementation.

>> 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).

I agree that role img for the image map <img>, *could* work.

>>>> 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.

It seems to me that, with ARIA and even with HTMl5's restrictions on 
its use, is is 100% possible to get lost in the wilderness. And so, 
ARIA relies on good authors or accessibility experts that do an 
analysis of how to best use it.

>> They say that ARIA is like CSS.
> 
> They do?

Or may be I mixed it up with what some said about RDFa. (Both ARIA and 
RDFa are based on RDF.)

>> And so, as author, I would like to use it as freely as possible.
  ...
> 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. 
  ...

I qualified with "as possible". 

>>>>>> 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?

I checked with AccProbe and it said 'link' plus something that was 
equivalent of "presentation". See dialog with Alexander.

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

When I checked with AccProbe, yes. See dialog with Alexander.
-- 
leif h silli

Received on Wednesday, 11 April 2012 11:34:17 UTC