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

Benjamin Hawkes-Lewis, Thu, 19 Apr 2012 07:23:20 +0100:
> On Wed, Apr 11, 2012 at 12:33 PM, Leif Halvard Silli:

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

Your wording here suffers from loss of context. But its sounds from 
everything you have said that you think of @longdesc as a last resort 
kind of thing. I don't view it like that.

> So does <a>. (When you follow a link, then press the back button, user
> agents typically return you to the original location.)

True, it can work work. And, by solving a few bugs, it could also work 
better.

But links can function in many ways: They can take you to a new page in 
the same window, or they can open in a new tab or window. Further more, 
the page you are reading, could be the one-page version of the HTMl5 
spec. Your connection to the internet can be slow or fast. And thus, 
there are many, many options. And so you perhaps rather want the link 
to work like a longdesc link.

The intention of a longdesc link, is to offer a method which does not 
have the drawbacks that a normal link can have. When the reader follows 
a longdesc link, he/she should feel assured that it is not as "risky" 
to follow it as a normal link could be. Also, he should also - as I see 
it - feel assure that the link leads to something that directly relates 
to the image — as opposed to be just a "Go to next page" link or 
something like that.

>>> 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".
> 
> I don't think you've concretely addressed how you're helping the user.

I added more above.

> This is a linked image:
> 
> <a href="link"><img src="link" alt="text"></a>
> 
> How user agents present/emphasise this is an implementation detail.

My point is that is should not only be a implementation detail. We are 
discussing two link semantics. I think it is pretty clear from the 
aria-describedAT discussion too, that it is supposed to have a specific 
semantic - it is not just like a normal link.

>>> 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.
> 
> But you haven't made a hidden link (@longdesc) work in every browser
> and every AT.

It was not my purpose that is had to be hidden. I was looking for the 
semantics. (I did also work on a kind of hidden link - but did not yet 
blog about it.)

>>> 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.
> 
> How would <a role="img"> help on the CNN front page?

The problem on the CNN page is that each news item is represented as 
two links: One link around an image, and one link around some text. The 
image comes before the text. This is confusing, I would say, as there 
should be only one link per each news item. By doing <a role=img>, the 
first link can be perceived as image rather than as link. I bet you 
disagree or see it from another angle, but this, to me, is less 
confusing.

>>>> 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.
> 
> Neither <span> nor <img> have an implied "presentation" role.

You are right about <img> - but we never disagreed about that. As for 
<span>, then I think you are wrong: ARIA 1.0 says, by example, that 
<span>abc</span> and <h1 role=presentation>abc</h1> are equal.

>> 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.
> 
> The draft spec for @aria-describedat made the element focusable.

OK. I had not gotten that - important - detail. Thanks.

>>>>>> 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.
> 
> HTML is too complex. HTML+ARIA is way too complex. That's not a good
> reason for just making it more and more complex.

Of course not. That's not why I want <a role=img> - to make it more and 
more complex.

>>>> 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".
> 
> I don't think the qualification makes any difference. You can remove
> all author conformance requirements and fully describe how any content
> should be processed by user agents. That determines what is possible,
> not what is conformant.

Sorry, Benjamin, but it is better to discuss the proposal at had, 
rather than claiming things about what the proposal implies.
-- 
Leif H Silli

Received on Thursday, 19 April 2012 18:40:53 UTC