- From: <bugzilla@jessica.w3.org>
- Date: Thu, 02 Sep 2010 00:40:31 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455 --- Comment #66 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2010-09-02 00:40:28 --- (In reply to comment #65) (In reply to comment #61) >> Like Shelley, I don't think we can expect Jaws to handle RDFa. I also think >> that A11Y people should not have to learn RDFa in order to make accessible >> pages. > > Covered both issues in my reply to Shelley in comment #64. OK. > > But couldn't a rel="d-link"/rel="longdesc" be compatible with your RDFa > > idea? Shouldn't they work together? Via RDFa on can be more exact about the > > relationship, I should think - not? > > Did you see my comment #50? You don't show any examples where the @rel appears inside an anchor/area element ... So I guess that's a diff between your and mine idea: You want screenreaders to treat some RDFa code the same way that they treat @longdesc - simply put, you want screenreaders to support "dark links" in RDFa. Whereas I suggest to link a behaviour to @rel="longdesc", only when used in <a> or <area>. Please note that in Charles's change proposal, then <img> would become defined as an interactive element. It seems like you operate with another understanding of "interactive" than he does ... But back to my question: are our ideas compatible, or not? Let us say that we agree about a definition of rel="longdesc" - whenever there is no RDFa in use. This would allow authors to become creative in using <area> and <a> to create longdesc link solutions. I am quite sure that many would come up with solutions. Then, also take in your idea: In addition user agents could implement support for a specific subset of RDFa - such as you showed in comment #50. The would the use the same rel="longdesc". Except that they would not need to use it inside an <a> or <area> element. > > Meanwhile, I don't believe a theory and/or principle based discussion of > > @longdesc can ever "reach home" unless we are also solve the fundamental > > practical problem that @longdesc raises: > > > > 1. @longdesc's relationship to @alt, especially to empty @alt > > (since empty @alt makes the img ignored). > > 2. What to do when/while there is lack of user agent support? > > Duplicate the @longdesc in a link? > > If you want your text alternative to be available to users of all user agents, > include it in-page or use a visible link, since these methods work in every > user agent and make the alternative discoverable by every user. > > > Regarding 2., then is it ever any good to duplicate a @longdesc URL in an > > anchor element? > > Yes, it can do *some* good. OK? > > Does the programmatic relationship of @longdesc generally outweigh the > > confusion that can be had when someone with Jaws get both a @longdesc > > announcement as well as a link to the same page? > > > > In other words: a main problem with @longdesc, as I see it, is that it does not > > offer "progressive enhancement/fallback" > > I agree that's a drawback of "longdesc" and, more relevantly to *this* bug, the > proposed new attribute. Yup. It would also be a drawback to the RDFa solution you suggest, though - unless you apply the RDFa to a "real" link element. > > A user agent supporting @longdesc should have a method for ignoring a link > > that is used for the same purpose, no? > > If it wants. Well, it should probably be optional, yes. > > Jaws does announce "visited link" if the link has already been visited. Fine. > > But the user may not understand that the visited link is in fact equal to > > @longdesc’s link. > > Duplicate links like the following are a common antipattern on the web: > > <a href="somewhere.html"> > <img src="somepic.jpg" alt="{Article title}"> > </a> > <a href="somewhere.html">{Article title}</a> > > How much does this antipattern confuse real users? Enough to make Jaws create a filter for the issue - according to what you say below. ;-) > I've known screen reader users to complain about clutter on web pages, but > inability to access a text alternative arguably constitutes a greater > accessibility barrier than the clutter of a duplicate link. Sure. So if a user cannot access the longdesc resource simply because his/her UA doesn't support @longdesc ... We have an accesibility issue ... Has anyone created javascript library that adds suppport for @longdesc, somehow? But it is *then* that one must start asking if it isn't necessary to add something to HTML which, by the right authoring choices, can be made to work in all user agents. I don't ask for removal of @longdesc, I just ask for the opportunity to create something that works for all. Adding some kind of RDFa microformat will not help (unless, of course, it is used inside a/area). Only a link based solution can be truly acessible her and now. Btw, w.r.t. to RDFa, you did see comment #15? There is a Issue in the RDFa Working Group (requested by yours truly) to define an RDFa mapping for @longdesc. You should perhaps see that threed - the working group seemed to be in favour of some kind of "hard coded" semantics for @longdesc. And I just wondered if rel="longdesc" etc should/can be "hardcoded" as well. (Probably best to discuss it "over there". > > If the UA were able to understand that a link is used in the same role as > > @longdesc, then they could possibly ignore the link. > > They could, though it's not without risk. > > If a UA ignored the long description annotation when the user reads the "img", > the user might never reach the long description link. But if it ignored the > long description link, the user might miss out on any additional JS behavior > the author attached to that control. But if that link had rel="longdesc", then it would have reason to trust that it could filter it out. > > Is JAWS, for instance, able to ignore a D-link that points to the same places > > as a @longdesc link pionts? > > JAWS 11 apparently includes a feature for automatically filtering out all > duplicate links: > > http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp Thanks for the info! > I don't know if it applies this behavior to "longdesc". -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 2 September 2010 00:40:36 UTC