- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 19 Apr 2012 20:40:19 +0200
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Alexander Surkov <surkov.alexander@gmail.com>, wai-xtech <wai-xtech@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
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