WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: LONGDESC in HTML5?

for

From: ckrugman
Date: Sep 28, 2010 9:33PM

as a screen reader user this is a very valid point. now if it would only
describe captcha images!
chuck
----- Original Message -----
From: "Cliff Tyllick" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Friday, September 24, 2010 4:58 PM
Subject: Re: [WebAIM] LONGDESC in HTML5?


>I apologize in advance for not including prior messages in this comment,
>but I would like to take this discussion in a different direction -- that
>is, to explain my perspective, childish though it may be ;-), on the proper
>role of an attribute within HTML5 that enables a connection to a
>description of an image. This will be a bit of a trip, but if you are
>invested in the discussion of whether to include longdesc in HTML5, stick
>with me.
>
> People who use screen readers have told me that they need images to be
> described to them if they are to interact successfully with the sighted
> world. Perhaps the issue is as trivial as not having to ask for help to be
> able to retrieve the picture of the boss in the purple shirt, not the pink
> one, from the intranet. Still, for various reasons they need to be able
> either to find out how to describe an image or to find an image from its
> description.
>
> Other people who use screen readers have told me that they need to know
> only the intended meaning of each image -- they insist, "Don't clutter up
> my ears with a description of meaningless pictures!"
>
> In short, the debate in HTML4 and XHTML was whether we should do this:
> alt=""
>
> or this:
> alt="our dear leader in his regal purple shirt"
>
> So we have two different needs, but within HTML5 we have only one
> attribute for accommodating those needs -- alt, which, as I understand it,
> is now explicitly denoted as the place to convey the meaning of the image,
> not the place to describe it.
>
> In HTML4 and XHTML, we did have a place to describe the image -- the
> longdesc attribute -- but, as I understand it, there was no distinction
> other than length between the intended purpose of alt and the intended
> purpose of longdesc. Both were meant for the description of meaningful
> images; longdesc was to be used when that description was too long for
> alt.
>
> When might that description get too long for alt? Well, one example would
> be when the image is a detailed graph or a complicated chart.
>
> So far, how often are those kinds of images presented in html? In my
> experience, less frequently than we see longdesc used. Usually such images
> would be in documents that started out in a word processor or publishing
> package, were converted to PDF, and were then loaded to the Web in that
> format. In some cases, the source file for the PDF was also loaded to the
> Web.
>
> And where, pray tell, do you put longdesc in a Word document, a PageMaker
> file, or a PDF? You don't. Those applications have no place to store a
> longdesc attribute. So the engines for generating the content that
> includes the kinds of images that most need a lengthy description afford
> no way to add that attribute to each image. Small wonder that people who
> insist on having examples of where longdesc find few, if any, that satisfy
> their skepticism.
>
> And what about the other end of the communication pathway? As Josh from
> Ireland pointed out, user agents have not come up to speed with
> interpreting longdesc when it *is* there.
>
> So this raises another problem with getting longdesc used: How does
> content get put on the Web?
>
> Am I the only person involved in this discussion who works in a setting
> where the people who create the content would not be able to function
> without WYSIWYG html editors? Our agency has scores of Web developers. But
> except for a very few, the work these folks do as Web developers doesn't
> fit into their job description at all. It's one of those "other duties as
> assigned," so it never really enters into their performance appraisal.
>
> We have relatively few employees who can stay up to date on accessibility
> and coding conventions. There's no way we can review, let alone fix, every
> content item loaded to our website. So it has been part of our job to
> educate, cajole, and wheedle these scores of developers into producing
> valid code and accessible content. We've made a lot of progress, even
> though we still have far to go.
>
> But we would have gotten nowhere if we hadn't picked our battles and
> focused on the issues that made the biggest impact -- structure, plain
> language, valid (x)html, and proper use of the alt attribute.
>
> In the grand scheme of things, longdesc -- its purpose poorly
> characterized in the specification; its need rare in content presented in
> html; the ability to add it to images that needed it nonexistent; the
> support for it by screen readers absent -- got left out.
>
> We hadn't gotten there yet. We were waiting for the tools to become
> available and for the production of content to shift to html-first and
> away from word processor + PDF only.
>
> How could we use longdesc for those images? Well, beyond the obvious
> purpose of affording a lengthy explanation of the image to people who
> can't see it, longdesc could provide a very real benefit to everyone who
> needs to know the finest detail behind a presentation. If people who could
> see could easily get to the lengthy description, authors could use it to
> go into the arcane arguments and rationalizations that are behind their
> illustrations, but that most readers don't even want to know about:
> - Why did you find it valid to suppress the zero on this graph?
> - Why is this histogram a valid presentation of this data set?
> - Why is the 33rd percentile income, and not the median income, the key
> value?
>
> In other words, now that you've described clearly the construction of this
> image, now tell me why this presentation is valid. People who can't see
> would benefit from at least the first part. People who can see would
> benefit from the second part, but also would sometimes benefit from the
> first. Have you never seen something in an image for the first time after
> the person who created it explained it to you? And have you never
> discovered something in an image that the person who created it failed to
> recognize?
>
> A place to link to descriptions of meaningful images -- descriptions
> beyond the level of detail that would typically be given in a caption or
> the accompanying article -- would give us richer capabilities in
> presenting, analyzing, interpreting, and understanding the meaning behind
> those images.
>
> But we don't have that in HTML5 any more.
>
> And so what's the solution? I've seen many proposed, but not one is native
> to HTML. And that means that if I am going to get my content creators to
> do it, first I am going to have to get them to learn something that is
> called by another name.
>
> But they're already feeling like they've learned far more than they should
> have to know under their job description. And in many cases, their
> supervisors agree. Heck, even I agree! So what are my chances of getting
> them to learn something called ARIA?
>
> None. It won't happen.
>
> That is what I work with every day. And I'll bet it describes the websites
> of many, many people who don't have the time to follow, let alone
> participate in, long-winded discussions of where we should take HTML from
> here.
>
> But you've let me digress. I started out talking about the needs of people
> who rely on screen readers, and here you've let me ramble on and on about
> the realities of distributed Web development.
>
> What was it the people who rely on screen readers need to know about
> images online?
>
> Sometimes, if it means anything, they need to know what it means. For
> this, we have alt text.
>
> Sometimes they need to have an idea how a person who can see the image
> would describe it. For this, we have a patchwork of partial solutions.
>
> But we could have solved it simply and completely in HTML5 with the right
> specification:
> - Use alt to convey succinctly the meaning you expect a person who can see
> this image to get from it. If the image is to convey no meaning, leave
> this attribute empty.
> - Use longdesc to link to a description of the image, even if the image is
> to convey no meaning. When the user requests, the user agent -- including
> browsers -- should open this description without leaving the current
> position in the document. Closing the description should return the user
> to the same location.
>
> So we would have instances like these:
>
> alt="stop" longdesc="[link to 'red octagon']"
>
> alt="" longdesc="[link to description of a calming pastoral scene]"
>
> alt="earnings have doubled from first quarter (Q1) to third quarter (Q3)"
> longdesc="[link to description of the graph followed by an explanation of
> why Q1 is being compared to Q3 and not to Q1 of the previous fiscal year]"
>
> People who feel the need to know what images look like would have a
> reliable location to look for that information. People who never want to
> be bothered with that information would never be troubled by it.
>
> And if we had such an attribute built into HTML5, I wouldn't care if we
> called it "longdesc" or, so long as longdesc continues to be supported as
> a deprecated attribute, just "desc" or "imgdesc" or some other name. The
> important point is that we have two distinctly different communication
> needs and in HTML5 as it exists today we are accommodating only one of
> them. We need to accommodate both.
>
> To accommodate both needs anticipates and prepares for the future. To
> accommodate only the need that has been accommodated thus far is to be
> forever looking backwards.
>
> That's my personal opinion, based on real experience.
>
> -Cliff
>