longdesc in HTML5
Yesterday, In tweeted “I know it’s important, & I know this makes me evil, but if I read any more about bloody longdesc in #html5 I’m gonna set fire to my scrotum”, thereby doing a dis-service to an important debate which has exasperated me due to the traditional enmities and personality clashes.
To make amends for my flippancy, today I’m writing about it.
The latest skirmish between the Accessibility types and Young Turk HTML5 types, which has left trails of dead and scorched earth across mailing lists, involves the longdesc attribute of the <img> element.
Never heard of it? Few have.
It’s an attribute that points to a URL where a long description of the image can be found. It’s not the description itself.
The trouble is, hardly anyone uses it correctly and there is little browser support. WebAIM has an example of longdesc, and there is nothing that indicates to a user, either visually or otherwise, that a longdesc is available. Opening the context menu in Opera offers an option “long description” which, if activated, opens the URL specified, but this doesn’t exist in any other browser except iCab (and is only a year or so old in Opera).
Extensions exist that give a visual cue that longdesc exists in Opera, and an extension by Patrick Lauke brings Firefox up to Opera’s native support.
But basically, discoverability is a problem, support is low, it’s used very little “in the wild”, and when it is used it’s badly used:
No more than one in a hundred get it right, of one in a thousand that even try
so the WHATWG wants to remove longdesc from HTML5.
Cue uproar from those involved in Web accessibility. They point to the fact that assistive technologies and authoring tools support longdesc and, they argue, if only the browsers would fix discoverability, a thousand longdesc flowers would bloom.
A recent survey by the splendid WebAIM people suggests that screenreader users love longdesc (although less than two years ago the same survey found it “very unpopular”. Why the sudden surge in popularity?)
Generally, I’m not in favour of hidden metadata that is meant only for one sector of the audience. Hidden metadata, because it’s hidden, easily falls out of step with the rest of the information. On the other hand, I’m not generally in favour of chopping things out of the language because it makes it harder for people to migrate from HTML4 to HTML5 and because I’ve seen the light after the <cite> debacle. And, although it’s hardly used anywhere, people claim to love it; I’m against removing something that makes their lives easier, particularly when there are enough impediments out there to their full and equal access to the Web.
So on balance, I prefer longdesc to stay. But I’d suggest that better practice is to use the HTML5 details element or aria-describedby and point to a resource that anybody can discover.
If you want to link to an off-page resource, Steve Faulkner suggests:
<img alt="2009 results table" aria-describedby="desc">
<a href="description.html" id="desc">description of table</a>
Removed as Steve has changed his mind.
Now, where’s my lighter?
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
55 Responses to “ longdesc in HTML5 ”
“Generally, I’m not in favour of hidden metadata that is meant only for one sector of the audience”
but if the long description is the details of what is in a picture of a bar chart doesn’t that fix a problem? Namely that the bar chart is data that is only meant for one sector of the audience – those who can view the image?
@Alan G: How many sectors “can’t” view the image? Would be nice if +98% of you audience could all be grouped into one ‘sector’.
> Cue uproar from those involved in Web accessibility.
No!
http://www.cssquirrel.com/blog/2011/02/23/w3c-control-to-major-tom/#comment-32376
@Mattur said:
Refering to Matturs ref to http://www.w3.org/2009/06/Text-Alternatives-in-HTML5:
Because we are confident that aria-describedby will be supported by assistive technologies at least as well as longdesc when HTML5 becomes a W3C Recommendation:
IF
aria-describedby is incorporated in HTML5
and aria-describedby allows pointing to long text alternatives that are off of the page (by pointing to a link on the page)
THEN
we believe it is acceptable to obsolete longdesc in HTML5.
Just to be clear, and yes we (sic) don’t have a Pavlovian response to @longdesc (and/or) other a11y issues. And yes we (sic) are trying to have discussion about text alternatives in HTML 5.
@bruce, please do set fire to your scrotum.
From my understanding, the issue is less keeping longdesc and more “If you’re going to yank it, what are you doing to replace it with that provides the same functionality?”
The request is for a way of providing a long description, in the page, or in another page. Your suggestions don’t meet this one request.
Normally in HTML, in the past, you don’t just obsolete something, you deprecate it in favor of something. This ensures that the functionality isn’t lost. It’s improved, but not lost.
Your argument about longdesc being “hidden metadata” implies that everyone perceives the web page through the same medium as you–your eyes.
The longdesc isn’t “hidden metadata” for those using screenreaders to view the page.
It’s no more “hidden metadata” than the nofollow value is with the link element–again, something meant to be perceived by an audience using a different means of perception.
And you’re approaching the issue from only one perspective. So what is the real problem with longdesc that makes the young HTML5 turks so determined to pull it and not replace it–at any costs?
I agree that this is an issue that should be resolved, sooner than later. I think the co-chair decision was dumb as bricks. They used some form of convoluted logic (this is “weak” that is “strong” objection) rather than acknowledge the very important fact that longdesc was pulled, and nothing was provided in its place that provided the same functionality. This was a fundamental flaw in their decision. And their perception of what is a strong or weak objection is more than slightly off.
As for people having used longdesc incorrectly, education works wonders. When you use data gathered through Google’s maw to make decisions, you can’t differentiate between early uses of longdesc–when there was little known about it–and use now, when people are better performed. This has always been why I’ve challenged such indiscriminate aggregating of Google data in order to make a decision.
Besides, I have no doubts–none–that much of HTML5 will horribly used and abused, now and in the future.
hgroup anyone?
Or…how about figure?
Aside?
Which came first? The article or the section?
PS
“chestnuts roasting o’re an open fire…”
“Generally, I’m not in favour of hidden metadata that is meant only for one sector of the audience”
I am only “hiding” because user agents developers don’t know how to signal my presence to sighted users. Even screen reader developers were slow in recognizing my existence. The solution to my underground existence is urging user agents and AT developers to provide better support, not throwing me under the bus. I don’t deserve that!
Well, as longdesc states (and that was a strange thing to write), perhaps the real problem is the tools, not the attribute.
I don’t perceive a disconnect b/n the image and the longdesc being a problem. Think about it: you have an image that’s complex enough that you feel you need a longdesc. Are you then going to swap out the image and leave the longdesc? And if you do, won’t you also note that the alt and the longdesc also need to change?
In my opinion, I think the real issue with longdesc is lack of familiarity and understanding of correct usage. I didn’t know about longdesc until recently, but now that I do, every time I’ll place a political cartoon in my web pages, I’ll use a longdesc. It’s ideal in these circumstances.
I like that Opera also provides a right mouse button menu item for the attribute. It’s a handy double check. And it’s a way of ensuring that if folks want to see the data, regardless of tools they use, they can.
> I agree that deprecation is preferable to removal.
It is NOT being removed!
It is being made non-conformant i.e. authors are advised by validators not to use it, but browsers are still required to expose it. So it’s effectively being deprecated.
For a person who likes semantics, I really don’t like semantic word games. I’m getting enough of those fighting the puppy mills in Missouri.
It is being made obsolete, mattur. People are being told NOT to use it. If it were truly deprecated, the people would be told to turn to another channel. However, they don’t have anything to use in its place. This is not deprecation, this is taking longdesc to a cliff and kicking it in the butt…saying ba-bye as the thing falls, tail over end to the jagged rocks below.
bruce, summary for TABLE and longdesc for IMG isn’t a case of “hidden metadata”, but, rather, “discoverable metadata” — for most users, such metadata may not be pertinent, but for other users, “discoverable metadata” is indispensable… in the case of @longdesc, most web users use their native brain/eyes support to provide them with contextual and navigational structures that do not need to be explained… however, for those with no gestalt view of the web document, such information is critical…
as for the sudden increase in the calls for longdesc by the screen reader using community, it derives, in part, from the heightened awareness that users now have about longdesc, due in no small part to the HTML WG’s chairs’ original decision to remove @longdesc from HTML5… the subsequent hue and cry which this raised, revealed both the need for verbose descriptors (in other words, a lot more people discovered what they were missing out upon) as well as documentating more extensive use of @longdesc “in the wild”, in addition to policies and guidelines (internal and external to companies and organizations) which mandate long descriptions using the @longdesc attribute… likewise, efforts such as that by IDPF to make EPUB 3.0 compatible with HTML5, and the trand towards utilization of electronic texts for scholastic and academic work, has highlighted within the screen reader using community the need for verbose description mechanisms in HTML5
and what did web analytics teach us about @longdesc? absolutely nothing, save for the limitations of authoring tools and individual authors — and, in any event, this attribute shouldn’t be subject to a popularity contest but is based on a clearly identified and articulated need… moreover, @longdesc was added to HTML4 expressly to address accessibility and equal access to information/content under a mandate from the director of w3c, tim berners-lee, and should never have been removed by the chairs without (a) an acknowledgment thatsuch a mechanism is needed, and (b) soliciting proposals on satisfying the well-identified use cases for @longdesc… attributes and elements introduced into HTML4 to increase accessibility, usability and internationalization should not be judged by mere “in the wild” numbers — they should be examined to ensure that their use cases are sufficiently addressed by the feature’s definition in HTML4, and if not, why not, in order to ascertain if they can be improved upon, not thrown out as so much chaff….
Hey Bruce,
Extracted from an earlier Rant, I offer you a review of the HTML5 Design Principle of “Users over Authors over Implementors over Code Purity”.
USERS:
We have an attribute. It does good things when used properly, and when misused it is relatively benign. It works well today for users of most commercial screen readers (80% rule), and can be used by sighted users who choose to either use a browser that supports @longdesc natively (Opera, iCab) or who wishes to install a plug-in or fine-tune their configuration to access the content (Firefox plug in, Sean Hayes’ recent MSDN blog post for IE support) (20% rule). Or is the 80/20 rule only for those *without* disabilities?
AUTHORS:
We have increased author awareness of @longdesc. We have HTML WYSIWYG editors today that allow authors to properly include @longdesc at the authoring layer. We have professional content producers (ePub, DIAGRAM Project) that want to use this attribute, and will in all likelihood use it correctly (after all the digital ink that has been spilled on this topic, I will bet a sizable sum of money on that).
IMPLEMENTORS:
We have implementers who have dragged their feet on doing something useful with @longdesc since 1999! And representatives of those user-agents arguing for the removal of @longdesc from HTML5, without once stepping up to the plate and tackling the alleged short-comings of the attribute. (Yet other user-agents – screen readers – *do* do something useful with @longdesc, so it’s not like the attribute cannot be successfully supported by user-agents…)
CODE PURITY:
The simple fact today is that if you wish to author an otherwise conformant HTML5 document, but then add @longdesc to an image in that document, the following will happen:
the page will continue to render fine in all GUI browsers
the URL of the @longdesc attribute will be written to the DOM as an attribute value of the <img> element
screen readers and other consuming user-agents that support @longdesc today will have access to the long description. Simply put, it still works.
HTML5 validators will throw an error message. (Oh dear!)
Epilogue
“A terrifyingly small percentage of the pages on the web pass a
validator. The far vast majority of pages doesn’t even nest their tags
correctly. The sad truth is that while we can do what you suggest,
it’s not going to have a big effect because people simply doesn’t
consult validators to a large degree.”
– Jonas Sicking (Mozilla)
“Indeed it’s one of our principles:
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
Interoperability and compatibility with existing deployed servers is
orders of magnitude more important to me than pedantic compliance to other
specifications. Specifications exist to help move civilization forward,
not to provide arbitrary restrictions on progress. When a specification
gets in the way of improving the Web, it should be changed or displaced.” – Ian Hickson
’nuff said.
oh, and one more thing…
But I’d suggest that better practice is to use the HTML5 details element or aria-describedby and point to a resource that anybody can discover. If you want to link to an off-page resource, Steve Faulkner suggests:
<img alt="2009 results table" aria-describedby="desc">
<a href="description.html" id="desc">description of table</a>
For your consideration:
“ARIA is intended to only affect accessibility API mappings (and thus ATs). Features such as alt=””, however, are relevant far beyond AT users, for example to text browsers. It would be wrong, therefore, to make solutions that exclusively affect accessibility APIs be a suitable alternative for solutions that are necessary for UAs that do not use accessibility APIs.”
– Ian Hickson
“The working group likes the idea of having built in semantics in HTML… For these reasons, we would promote the use of such markup over the ARIA approach.”
– Al Gilman (former) Chair of the W3C Protocols and Formats Working Group
My gripe with longdesc would be the terrible name, to be honest. It isn’t clear that it points to a description, rather than describing the image itself. I can see why authors would mistakenly put the description into the attribute value, given the ambigous name. With aria-describedby it’s much easier to understand the purpose of the attribute. Also, aria-describedby is more generic, since you can use to point to the description of any resource (audio, video, images etc.), which is another plus for describedby in my opinion.
I could be wrong, but I think aria-describedby takes an element ID, rather than a URL, as an argument, so can’t be used to point to an external resource. That might be an argument in favour of keeping longdesc.
I’m not sure about the hidden metadata argument. Browser manufacturers say ‘we shouldn’t implement this because it’s hidden from the user’ yet they do realise that they can change this since they control the implementation, right?
Quick question: Can longdesc point at another element in the same page, e.g. using a hash fragment doobrey like longdesc=”#description”?
Quick answer to Olly: yes.
Longdesc takes a URI as a value, so “#description” should be valid in the same way that href=”#description” is valid.
I guess an example might be something like the photo at
http://www.nmm.ac.uk/collections/displayRepro.cfm?reproID=P27518&#fullscreen
which is described by
http://www.nmm.ac.uk/collections/explore/object.cfm?ID=P27518
It’s not uncommon to have a large photo on one page, and a description of that photo on a different page (or at a different URL). Flickr is another good example.
Sorry, forgot to add – where an image and metadata are at separate URLs, like that museum example, then RDFa is probably better than longdesc for linking them together. The WHAT-WG would love that, I’m sure.
@bruce
thanks for digging up an email I have no recollection writing, not uncommon for me, my memory is failing. The response I provided in the email is incorrect. aria-describedby does not work the way I thought is should/would. In fact that example would actually reduce the accessibility.
I have recently come back around to supporting the inclusion of longdesc in HTML5, for the following reasons:
1. spending 2 days in a locked room with john foliot at the San Diego W3C accessibility taskforce face to face.
2. I realized there is a strong commitment in the W3C accessibility community to including a dedicated feature in HTML5 that unambiguously and explicitly associates a description of an image with the image it describes. So wanted to be part of the process of that influences what form this feature will take.
3. John showed me dirk ginaders longdesc jquery plug in
4. One of the issues in regards to how this feature (that unambiguously and explicitly associates a description of an image with the image it describes)is currently implemented and specced that turned me off it is its discoverability.
Realizing that the feature known as ‘longdesc’ can be used AND its OK for the resource to be discoverable for all users and that this was a viewpoint shared by others in the accessibility community.
5. realizing that replacing longdesc with a modified aria-describedby will result in its use continuing to be only for the benefit of those that may find it useful.
I am sure there are other reasons too.
So if its understood that as currently implemented it has limitations, but those limitations can be overcome by the author as in ‘HTML5 NOW’ where there is a polyfill for most any feature that just don’t work yet! and the feature can be specified (unfinished symphony) so its implementation and use can be improved. Then hey, why not give it a go.
errata
5. realizing that replacing longdesc with a modified aria-describedby will result in keeping it hidden for some and its use continuing to be only for a SUBSET of those that may find it useful.
@bruce
“it’s still better to use HTML5 <details>, for discoverability, in the long run”
what I am still not clear about is
a) is/will including an image in the <summary> element for the purpose of binding to a description of the image be considered as semantically correct?
b) will it be practical across browsers to use this method (will not be known until browsers actually implement details/summary)
c) how will the semantics/functionality of the <summary> (actionable label for the button/disclosure widget)work with conveying the accessible description relationship between <details> and <summary>
so I would say that in the long run <details> MAY be prove to be a useful method.
1. spending 2 days in a locked room with john foliot at the San Diego W3C accessibility taskforce face to face.
In my defense, no visible bruises were produced.
Bruce, re DETAILS – this *might* be a useful solution in some instances (once we get browser support and) screen reader support, and can be sure that screen reader users, like sighted users, will be able to skip past that content without being forced to consume it. Choice is good: DETAILS would be an alternative choice over longdesc, not a replacement.
I wouldn’t use details. For one, summary part of details is just — a summary. An image isn’t a summary for the textual description. An image and the textual description are really peers: the same thing expressed in two different mediums.
Or two different media.
@bruce
Simply Placing the details after the image doesn’t satisfy the requirement for an explicit and unambigous association unless every time this pattern occurs the details content is a description of the imagecontent.
Likewise placing the image to be described inside the summary does not satisfy the unambiguous association requirement unless the only time an image is included as content of the summary is when the details content describes the image. I think we can agree that this is an impractical constraint on the use of details. So if if the unambiguous association requirement is accepted as legitimate then even if details is used there still needs to be a semantic flag which disambiguates the relationship.
You wrote: “Cue uproar from those involved in Web accessibility.”
You meant: “Cue uproar from some of the people involved in web accessibility.” There are plenty of us involved in accessibility who would be happy to see longdesc die a fiery death in lieu of your scrotum.
WebAim, RNIB and others currently recommend in-page text or a normal link over using longdesc. At what point does a programmatically-determinable longdesc become more accessible than a non-programmatically determinable in-page description or normal link?
For example it’s hard to see how http://www.agrip.org.uk/logodesc/ would be improved by using longdesc. The description is currently accessible to everyone, but isn’t linked to the actual logo image at all (it’s a CSS background image).
Is it an essential for longdesc to be invisible as per Laura’s CP or does longdesc need to be Perceivable to all? Do users actually understand the difference between a longdesc link and a normal link, and benefit from that knowledge? Or are we just imposing pointless complexity on users for tradition’s sake? Do we also need a long description attribute elsewhere eg for linking to an explanation of a complex word or phrase, or are normal links ok for that?
My understanding is the HTML A11Y TF is about to poll on whether to reverse it’s previous decision on longdesc, so perhaps this will all become clearer this week.
@mattur
“WebAim, RNIB and others currently recommend in-page text or a normal link over using longdesc. At what point does a programmatically-determinable longdesc become more accessible than a non-programmatically determinable in-page description or normal link?”
At the point where the association is unambiguous to those that require it, but the link to the description is available to anyone.
But asking when one should be used over the other is asking the wrong question, both can be used.
“Is it an essential for longdesc to be invisible as per Laura’s CP or does longdesc need to be Perceivable to all?”
How browsers display content is not a RFC MUST in HTML5 by design. Browsers are free to present content to users as they see fit. That is why we have longstanding accessibility issues such as title attribute content not being available to all.
One of the things that we agreed upon at the san diego f2f is that browser SHOULD provide a method for all users to access the content referenced in longdesc. Until a time when/if that does occur I think best practice would be to use a combination of discoverable link + longdesc.
[…] discussion on @longdesc continues. In a comment to a weblog post, Bruce Lawson questioned whether the <details> element can't be used in place of longdesc. He continued the […]
It would be extremely helpful if @mattur stopped spreading false information around the web. If he spent 1/10th the amount of time actually trying to get browser vendors to do a better job with @longdesc as he did trying to break the web by killing off a valid and useful HTML4 attribute in HTML5, the problem would have been solved years ago. For absolute clarity (and I note that @mattur won’t actually quote WebAIM) they state:
While modern screen readers provide good support for longdesc, a problem arrises in using longdesc exclusively – browsers do not currently provide any visual indication that the image references a long description page. Many browsers do provide this information in the image details or context menu, but this is not readily apparent. The longdesc approach is a technique recommended in both the Web Content Accessibility Guidelines and the Section 508 guidelines. It would have much better utility if modern browsers and other assistive technologies provided a more apparent method of identifying and accessing long description pages. – http://webaim.org/techniques/images/longdesc#longdesc
Further, to be even clearer, on Sept. 24, 2010 Jared Smith of WebAIM wrote:
We’ve had discussions about this and there are varied opinions even internal to WebAIM. Despite there being arguments for dropping longdesc, it is our opinion that longdesc should NOT be made obsolete in HTML5. – Jared Smith
With regard to the RNIB: in a 3 year old blog post, a RNIB staffer did suggest removing @longdesc, but went on to comment:
It would be wonderful if we could get all user agents to implement the specifications for all elements and attributes correctly. But how soon is it going to happen? When did complaints about IE rendering of the ALT attribute begin? I believe that we should keep trying, but am suggesting what I hope are workable alternatives, “until user agents …”.
I was being deliberately controversial in suggesting that LONGDESC is removed from the web authors accessibility toolbox, hoping for a comment like yours. We put pressure on where we can, but the web community at large has to get behind calls for adherence to standards…
LONGDESC is just a kind of shorthand, but it needs to be handled in browsers in such a way that allows everyone to access the long description. – Dave Wailing / RNIB
@mattur, please, PLEASE stop spreading false information – you do nothing but continue to discredit yourself in your attempt to cause uncertainty and confusion.
As for the W3C “polling to reverse its decision” on @longdesc, as an actual attendee of that Face-to-Face meeting I can report that there is no disharmony on the Task Force nor Protocols and Formats Working Group stance – those involved in the discussions are solidly in favor of the retention of @longdesc in HTML5. In fact, as one of the topics of discussion, and an outcome of those meetings, was to develop draft text for the Authors Guide. Furthermore, based around those discussions, we now have an Opera browser extension that does place a visible indication in the browser chrome when @longdesc is present in a document, and I anticipate similar plug-ins for IE, Firefox, Chrome and perhaps even Safari within the next few weeks: solutions that partially address the discoverability problem for sighted users (until such time as the browsers themselves do something natively).
There is no debate that @longdesc should be more discoverable to users NOT using screen readers (a point discussed and agreed to at the Face-to-Face, and the conclusions of both WebAIM and the RNIB blog author). WE ALL AGREE!
However, if the larger community believes this as well, then I urge them (you) to tell the browser vendors this, and advocate for better in-browser support for this attribute. Let’s stop talking about throwing the baby out with the bath-water.
The “problem” today is not @longdesc, but the fact that the browser have done nothing with @longdesc in the past. Further, it seems that the voices continuing to cry for the removal of @longdesc from HTML5 seem to be coming almost exclusively from people who work for browser vendors.
Coincidence?
John Foliot:
WebAim’s longdesc article lists long description alternatives going from most preferred to least preferred. In-page is most preferred, then normal link, then longdesc, then d-link.
The RNIB’s Surf Right (Word .doc) Aug 2010 standard says:
Quote:
“A long description of the information conveyed by a complex image needs to be provided in one of the following ways:
In related text on the same page.
On a separate page, with a link to that page placed next to the image (for instance “Full text description of the information presented in graph A above”),
Note: we don’t recommend the use of the LONGDESC attribute because it isn’t available to users without screen readers. The long description should be made available to everyone who can’t process information conveyed in images, whether or not this inability is sight related.
[..] If LONGDESC attributes are used, they must have a URI as their value, and result in a page that provides a long description. If an image is a link, it should never also have a LONGDESC attribute, as there’s currently no mechanism available to follow both the LONGDESC URI and the link URI. The result is that the LONGDESC activation cannot function, making the long description unavailable.”
Re: the HTML-A11Y-TF polling thing, I’m referring to the TF minutes from 24th which say:
“John [Foliot] to send a draft statement on longdesc to the TF by early next week, in anticipation of polling the TF to measure agreement on the position statement in that draft [recorded in http://www.w3.org/2011/03/24-html-a11y-minutes.html#action01%5D“
Oh. My. God.
WebAim’s longdesc article lists long description alternatives going from most preferred to least preferred. In-page is most preferred, then normal link, then longdesc, then d-link.
Yep, third choice is to use longdesc. Nothing inconsistent here, and an authoring advice to use longdesc. No reason to obsolete it. Not contradictory with Jared’s statement about retaining @longdesc in HTML5. Your point? If browsers did something more useful with @longdesc for their sighted users, this would overcome the discover-ability problem. Don’t blame the attribute, blame the browsers.
The RNIB’s Surf Right (Word .doc) Aug 2010 standard says:
Standard? or White Paper? Can you tell us *one* entity or instance where authors are mandated to create content per this document?
Quote:
“A long description of the information conveyed by a complex image needs to be provided…
No disagreement.
Note: we don’t recommend the use of the LONGDESC attribute because it isn’t available to users without screen readers. The long description should be made available to everyone who can’t process information conveyed in images, whether or not this inability is sight related.
Once again, this is a browser problem. If browsers did something useful, this would not be an issue. Things are changing here: we have support native in some browsers, and plug-ins to address this short-coming for other user-agents are emerging. How does this justify obsoleting @longdesc? Don’t blame the attribute, blame the browsers.
[..] If LONGDESC attributes are used, they must have a URI as their value, and result in a page that provides a long description. If an image is a link, it should never also have a LONGDESC attribute, as there’s currently no mechanism available to follow both the LONGDESC URI and the link URI. The result is that the LONGDESC activation cannot function, making the long description unavailable.
See above. If browsers would adopt the contextual menu pattern that is emerging as a preferred exposure mechanism, then screen readers like NVDA would be able to expose both links to the end user (or so Jamie and Michael – developers of NVDA – told me at CSUN). Once again, don’t blame the attribute, blame the browsers.
Re: the HTML-A11Y-TF polling thing, I’m referring to the TF minutes from 24th which say:
“John [Foliot] to send a draft statement on longdesc to the TF by early next week, in anticipation of polling the TF to measure agreement on the position statement in that draft [recorded in http://www.w3.org/2011/03/24-html-a11y-minutes.html#action01“
Yes, that would be MY action item, and to be crystal clear, it is to ensure we have language we can bring to the Task Force around supporting the re-instation of @longdesc to HTML5.
I was on that call, I volunteered to take the action item, and I am 100% clear in my mind what it is that is expected of me. There is no hesitation, no confusion, no “maybe they will change their mind about @longdesc because Matthew Turvey keeps re-hashing old excuses that have been answered numerous times before on numerous other fora.”
Matt, here’s the bottom line:
N O B O D Y is forcing you or any other author to use @longdesc. If you think it is critically flawed, don’t use it, use one of the other methods – just be sure that longer textual descriptions are provided of complex images. How you do it, we gladly leave to you.
Stop trying to impose your ideas as the one true way forward – no such thing exists. No-one has argued that @longdesc today does not have some usability issues for sighted users. (Although evidence to support this assertion has never been provided – we have zero proof that most/some/any sighted user has requested this ability)
The solution however is to not walk away from an established 10 year old attribute, wreaking havoc on existing content, when the other option is to work with browser vendors to get it right this time. One is a positive approach, the other is a fatalistic and negative approach. I am actively working with engineers and developers to improve how @longdesc can be consumed by all users – witness Sean Hayes’ blog posting for longdesc support in IE. These engineers are listening and understanding that the problems with @longdesc today can be overcome.
The use cases have been made, the examples of possible GUI implementation are coming forward, and affected parties are talking *to* each other (as opposed to at each other – something I very much feel is one of your current issues). If the discover-ability concern can be overcome, I am very confident that RNIB will change their White Paper position (in part, because I’ve asked), and that Jared and his WebAIM team will look even more favorably at @longdesc as a viable possible solution (I know, because I asked), along with all the other possible solutions, for ensuring longer textual descriptions to complex images. (And before you try to invoke Richard Schwerdtfeger’s name, I’ve spoken with him too. He agrees that the discover-ability problem is a problem, but he also supports the idea that fixing @longdesc is the best way forward – but don’t believe me, ask him yourself).
What positive news can *you* bring to this discussion?
[…] longdesc in HTML5 […]
John Foliot:
You may remember my original point was that RNIB and WebAim currently recommend an in-page description or normal link over longdesc, so asking at what point using longdesc becomes more accessible than using these other techniques seems to me to be an entirely valid question.
The original HTML A11Y TF polls found the TF did not want longdesc to continue forever, and that aria-describedby should replace it. Since aria-describedby is now viewed as unsuitable, I think the TF will probably reverse that decision. Regardless, the polling will presumably make the TF’s current position clearer. I didn’t mean to imply you were having a cow about it.
The RNIB’s Surf Right standard replaces the previous See IT Right standard, and is used by the RNIB for site audits.
longdesc is, surely, the ‘Radio 4 Shipping Forecast’ of element attributes?
there is NO stipulation that the content of @longdesc should never be displayed–for those who need guidance through the complex image (because of cognitive issues or anb extremely small viewport)
the claim that @longdesc discriminates against users is fallacious — what discriminates against users is the lack of UA support for @longdesc discoverabily, a non-AT method of invoking the long description, and configuration options within UAs which a user can then use to decide how to best present the long description according to that users’ needs
again, there is a difference between hidden metadata and discoverable metadata — categorizing information intended to be programmatically determined for specific groups of users as “hidden” is a canard — @summary for TABLE and @longdesc for IMG were added to address perceptual black holes and uninformed web browsing, and should not be measured with the same metric as valid @src values for IMG — they were added for a reason, and they should STAY in HTML until an equivalent or superior mechanism has been identified…
don’t blame the element — blame the implementors of browsers and authoring tools…
a note on the comments — i was not aware that underneath the TEXTAREA available for comments, one can check one’s comment via a dynamic region below the TEXTAREA — as a blind user, i have no idea that there is a review functionality, for there is no prose indication preceding or attached to the FORM to alert me to the preview’s existence… it is not intuative to surmize that after the “Submit Comment” button there more content appears on the page — could you please explicitly state that there is a preview function?
@brucel
since there isn’t any prose preceding the comment form, it isn’t self-evident that the preview follows the submit button — i think that you should consider the following:
a) a prose string indicating where one can find the preview pane
b) personally, i would make the comments section a live region, but you will hear differing opinions on use of a live region given state-of-the-art support for live regions, because speech output users like to be in control of what they hear, and some may object to the double echo (first from keyboard voice when typing, second from live region reporting); case in point: the live region on accessibletwitter that monitors how many characters are left in the tweet edit field — i like having this info auto-announced, but i know several colleagues who hate having a live region “forced” upon them, and i can imagine that for a user using supplemental speech due to cognitive issues, such double-speak would be maddening… AT support for live regions isn’t yet robust enough to allow the user effective control over live regions (indicate and read, indicate and don’t read, read-automatically, etc)
c) i think that one way to solve this using native markup is to have the preview encased in a BLOCKQUOTE, thereby making it possible for users to use the “next quote” navigational tool provided by their AT to preview one’s comments to toggle between the TEXTAREA and the preview
basically, the problem is that if i’m not told where something is or even that it exists, i will never know where to look for it, so a simple first step would be to alert the user that a preview is avaiable as a blockquote immediately following the FORM/submit button — also, the “notify me of follow-up comments via email” checkbox should precede the “Submit Comment” button, so that it is clear that this is an option available to commentors — i just discovered the checkbox myself only through playing around with the page in order to test the page…
[…] may have heard some discussion about “longdesc” recently which spiked when much debate broke out on whether to keep it in the HTML5 specification. Unless you’re a “veteran” web professional, […]
[…] may have heard some discussion about “longdesc” recently which spiked when much debate broke out on whether to keep it in the HTML5 specification. Unless you’re a “veteran” web […]
[…] to ensure that @longdesc remains in the specification. Meanwhile, there have been a rash of blog posts over the past few weeks that have also emerged, and if you are in any way interested in HTML5 […]
[…] 'large',}0You may have heard some discussion about “longdesc” recently which spiked when much debate broke out on whether to keep it in the HTML5 specification. Unless you’re a “veteran” web professional, […]
[…] about the advantages of HTML5 to make your site more accessible in an article by Bruce Lawson, Steve Faulkner (May 25, […]
The value of the longdesc attribute is:
var x=document.getElementById(“compman”);
document.write(document.getElementById(“compman”).longDesc);
[…] longdesc in HTML5 by @BruceL (March 2011) […]
Pointing off-screen to another URL seems clunky at best. I’d agree that aria-describedby or another on-screen description is better suited.
Pointing to a different URI makes off line apps easier to break when developers forget to cache the extra resources.