E-mail List Archives
Thread: LONGDESC in HTML5?
Number of posts in this thread: 33 (In chronological order)
From: John Foliot
Date: Fri, Sep 24 2010 11:06AM
Subject: LONGDESC in HTML5?
No previous message | Next message →
Hi Jared,
As many on this list know, there is currently some controversy surrounding
the retention of the LONGDESC attribute in HTML5. The current Draft
Specification has obsoleted LONGDESC completely, despite the
recommendation from the Joint Task Force (WAI/PFWG and HTML WG) at the W3C
to retain it. (There is also a Formal Objection to this logged at the W3C,
as many accessibility advocates believe this is a bad decision)
Recently, some people who believe that LONGDESC should be dropped from
HTML5 are pointing to the WebAIM article at
http://webaim.org/techniques/images/longdesc as "proof" that accessibility
experts think that LONGDESC should no longer be used or supported. I
believe that they are misrepresenting what WebAIM is saying, but would
like to get some clarification "For The Record"
Does WebAIM believe that LONGDESC should be dropped from HTML5?
Thanks Jared!
JF
===========================
John Foliot
Program Manager
Stanford Online Accessibility Program
http://soap.stanford.edu
Stanford University
Tel: 650-862-4603
---
Co-chair - W3C HTML5 Accessibility Task Force (Media)
http://www.w3.org/WAI/PF/HTML/wiki/Main_Page
============================
From: Jared Smith
Date: Fri, Sep 24 2010 1:06PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
On Fri, Sep 24, 2010 at 11:02 AM, John Foliot wrote:
> Does WebAIM believe that LONGDESC should be dropped from HTML5?
As John notes, there is much controversy surrounding the longdesc
attribute. 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.
I've made some minor updates to our longdesc article
(http://webaim.org/techniques/images/longdesc) to clarify our
recommendations for its use.
Longdesc is not an optimal approach, but it is an accepted approach
and one that is codified as an acceptable and recommended technique in
international and U.S. laws and guidelines, including Section 508 and
WCAG 2.0. While it does not have widespread use and is often misused,
obsoleting it in HTML5 is not a viable solution - and is one that
would cause confusion and result in mixed messages.
There is no question that we need better methods for providing longer
image descriptions. Like many things in accessibility, we certainly
need better support in browser and assistive technologies. The HTML5
working groups and those in the accessibility field are bright people
- the brightest of people. We're capable of coming up with something
that will work and will work better. But as of right now, longdesc
provides functionality and accessibility that is not available in any
other way. For a page that is fully accessible and compliant today to
suddenly be flagged as non-compliant and as using a non-compliant, yet
widely recommended accessibility technique simply due to transitioning
that page to an HTML5 DOCTYPE certainly goes against the
backwards-compatibility and interoperability objectives of HTML5.
Jared Smith
WebAIM
From: Jukka K. Korpela
Date: Fri, Sep 24 2010 1:39PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Jared Smith wrote:
> As John notes, there is much controversy surrounding the longdesc
> attribute.
It's waste of time. Nobody outside the small circle of accessibility
advocators ever took longdesc seriously, still less used it in authoring.
> I've made some minor updates to our longdesc article
> (http://webaim.org/techniques/images/longdesc) to clarify our
> recommendations for its use.
That's pointless. Minor updates mean nothing, and major updates would not do
much good either.
> Longdesc is not an optimal approach, but it is an accepted approach
Accepted by whom? Some organizations pretending to be like standards bodies,
I presume. I don't thin 99.99% of werb page authors ever heard of the
attribute, still less accepted it.
> and one that is codified as an acceptable and recommended technique in
> international and U.S. laws and guidelines,
There are no international laws. US legislation pertaining to
government-funded sites might say this or that about the issue, but this
just means that they impose pointless burden on authors without achieving
any improvement in accessibility. Please provide actual evidence if you
thinkg otherwise; and evidence means showing that there is actual
improvement in accessibility (URLs welcome...).
> There is no question that we need better methods for providing longer
> image descriptions.
So include links to such descriptions if they are really useful.
> But as of right now, longdesc
> provides functionality and accessibility that is not available in any
> other way.
Completely wrong. The attribute just pointlessly duplicates the idea of a
link, making itself dependent on some fancy support to a longdesc attribute,
as opposite to a normal link.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: John Foliot
Date: Fri, Sep 24 2010 2:30PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Jukka K. Korpela wrote:
>
> Jared Smith wrote:
>
> > As John notes, there is much controversy surrounding the longdesc
> > attribute.
>
> It's waste of time. Nobody outside the small circle of accessibility
> advocators ever took longdesc seriously, still less used it in
> authoring.
Jukka, with all due respect, you are simply wrong here. Further, if you
believe that using @longdesc is a waste of your time, don't use it -
nobody is putting a gun to your head.
The simple fact of the matter is that while adoption has been slow, there
are numerous cases of its usage, and documented existence of laws,
policies and guidelines that suggest your current opinion is not correct.
(http://www.d.umn.edu/~lcarlson/research/ld.html#glps)
Removing the existing @longdesc attribute from HTML5 breaks the basic
premise of HTML5 being backward compatible, and for those who *must* use
@longdesc due to their workplace requirements, it effectively means that
they cannot move towards using HTML5. Nothing you can say or argue removes
this fundamental fact.
*EVERYONE* who has worked on this issue within the standards bodies and
process agrees that there may be more effective means of ensuring access
to longer descriptions of images in many instances, but virtually none
believe that @longdesc is not a useful technique - one of many - that
should remain within the web author's toolkit. @longdesc fills a need, one
that is not met by any other native semantic means.
Seeking to keep a rich and useful toolkit to improve accessibility is not
a waste of anyone's time, except apparently yours. That's too bad really.
JF
From: Joshue O Connor
Date: Fri, Sep 24 2010 2:36PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
On 24/09/2010 20:38, Jukka K. Korpela wrote:
> Jared Smith wrote:
>
>> As John notes, there is much controversy surrounding the longdesc
>> attribute.
>
> It's waste of time. Nobody outside the small circle of accessibility
> advocators ever took longdesc seriously, still less used it in authoring.
Yes, but that still doesn't negate the need for a long descriptor,
whether it is @longdesc or something better. The audience for this
functionality may be relatively narrow (academia etc) but it is a valid
audience nonetheless.
FWIW, I agree with _some_ of Jukkas points but I sincerely want to ask
what he suggests?
Agreed, the current implementation has been pretty unsuccessful but does
that negate the need for a longdescriptor in HTML 5?
Others within the working group, have used the angle of unsuccessful
take up by authors as a rational for culling (in particular)
accessibility elements/attributes. I think this is a terrible, myopic
logic. Is it not better to have something that functions, has some kind
of cowpath (however small) - that could be built on, or do you prefer a
year zero approach, and if so what?
FWIW, I think that UA support for @longdesc has been the real culprit,
and not necessarily shortcomings with the attribute itself. Without some
kind of breakthrough in thinking I sense we may be having this
discussion again in ten years..
Josh
********************************************************************
National Council for the Blind of Ireland (NCBI) is a company
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626).
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Jukka K. Korpela
Date: Fri, Sep 24 2010 3:21PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
John Foliot wrote:
>> It's waste of time. Nobody outside the small circle of accessibility
>> advocators ever took longdesc seriously, still less used it in
>> authoring.
>
> Jukka, with all due respect, you are simply wrong here.
In which point exactly? Can you cite actual use of longdesc attributes in a
manner that makes content more accessible to real people using real
browsers?
> The simple fact of the matter is that while adoption has been slow,
"Slow" is euphemism for "nonexistent" here.
> there are numerous cases of its usage, and documented existence of
> laws, policies and guidelines that suggest your current opinion is
> not correct. (http://www.d.umn.edu/~lcarlson/research/ld.html#glps)
You are not citing any actual usage, still less pointing out why it would be
beneficial in accessibility terms, just referring to a compilation of
accessibility policies which are, to be honest, just documents people have
produced without making anyone change their authoring habits.
> Removing the existing @longdesc attribute from HTML5 breaks the basic
> premise of HTML5 being backward compatible, and for those who *must*
> use @longdesc due to their workplace requirements, it effectively
> means that they cannot move towards using HTML5.
That's fine. They, or the powers behind them, must stop pretending that some
illusionary attributes promote accesssibility. It would be wrong to help
them in living in such illusions (avoiding all the hard work that real
accessibility might imply).
> Nothing you can say
> or argue removes this fundamental fact.
There's no "fact" involved. Please don't obscure things by calling the
policies that someone might favor "facts". Real facts are things that all
people agree on, because they are directly observable - no need for
"policies" and "opinions".
> *EVERYONE* who has worked on this issue within the standards bodies
... must have observed how far they are from the reality. (I presume you
mean real standars bodies, such as ISO and CEN, not industry consortia,
which tend to be a little less unrealistic.)
> but virtually none believe that @longdesc is not a useful technique
And nobody can cite an example of its being actually useful. And I mean the
URL of a real web page, not a contrived and typically childish example of
how it "might" be used.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: Cliff Tyllick
Date: Fri, Sep 24 2010 6:00PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
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
From: John Foliot
Date: Fri, Sep 24 2010 7:21PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Jukka K. Korpela wrote:
>> It's waste of time. Nobody outside the small circle of accessibility
>> advocators ever took longdesc seriously, still less used it in
>> authoring.
>
> In which point exactly? Can you cite actual use of longdesc attributes
> in a
> manner that makes content more accessible to real people using real
> browsers?
* Opera and iCal take @longdesc seriously by providing in-browser support.
* The Firefox plugin is a serious attempt to plug a hole in Firefox (due
to its lack of native support)
* JAWS, WindowEyes, Hal/Supernova have taken serious steps to support
@longdesc
* Laura Carlson's list of examples in the wild of @longdesc usage
represents a serious attempt to show where longdesc is being used
* Web cartoonist Kyle Weems (CSSquirrel) has both a perfect use-case for
longdesc, as well as demonstrable use of it on his site. The fact that he
also uses a 'hack' with aria-described-by pointing to an off-screen link
to the long description of his cartoons is also a serious illustration of
why a mechanism such as longdesc has value, as well as proof that other
techniques available to authors are less useful.
*Dreamweaver, XStandard, CKEditor (to name but 3) WYSIWYG editors provide
content authors with a means to include longdesc in web pages
* Michael Fields (a Portland based web developer) recently created a
WordPress plugin that allows authors to include longdesc into their
WordPress blogs. Michael is neither a "web accessibility" specialist nor
Standards wonk - he is simply a web developer who recognized both a useful
solution, as well as addressed a perceived (and real) need in the
authoring platform of his choice.
Are you suggesting that none of these examples are serious or real? I
might also point out that, from a technical perspective, the longdesc
attribute creates its own node in the DOM, after which any DOM aware web
technology can take that data-point and process it as it chooses.
Seriously.
>
> You are not citing any actual usage, still less pointing out why it
> would be
> beneficial in accessibility terms, just referring to a compilation of
> accessibility policies which are, to be honest, just documents people
> have
> produced without making anyone change their authoring habits.
Again, I refer you to Laura's research page
(http://www.d.umn.edu/~lcarlson/research/ld.html), which has numerous
documented uses of longdesc in the wild. Places like the United Nations,
US Federal and State governments, other European governments as well as
academic institutions and commercial companies such as Oracle.
>
> > Removing the existing @longdesc attribute from HTML5 breaks the basic
> > premise of HTML5 being backward compatible, and for those who *must*
> > use @longdesc due to their workplace requirements, it effectively
> > means that they cannot move towards using HTML5.
>
> That's fine. They, or the powers behind them, must stop pretending that
> some
> illusionary attributes promote accesssibility. It would be wrong to
> help
> them in living in such illusions (avoiding all the hard work that real
> accessibility might imply).
Are you suggesting then that using longdesc breaks accessibility? That the
best way to promote accessibility is to not use longdesc when it is
appropriate?
Pretending that authors will always provide either in-the-clear text that
repeats what is visually obvious to sighted users on the same page as a
complex image, or provide a visual link to that information elsewhere ("D"
Link?) will somehow improve accessibility, and that they will always do
this? Let's see what one designer says to that:
"However, as a designer, I object to being told I must use those
links myself. As you've pointed out on Twitter, the current design of the
comic page would certainly support a hyperlink wrapping around the comic.
However, my upcoming design already has functionality mapped to clicking
the comic, and won't have space for a large "transcript here" hyperlink
sitting around in plain sight (which would be distracting for the 99% of
my users that are sighted). In that scenario, longdesc can and does serve
my needs."
http://www.cssquirrel.com/2010/08/16/comic-update-alone-in-the-pitch-black
-dark/#comment-32126
>
> > Nothing you can say
> > or argue removes this fundamental fact.
>
> There's no "fact" involved. Please don't obscure things by calling the
> policies that someone might favor "facts". Real facts are things that
> all
> people agree on, because they are directly observable - no need for
> "policies" and "opinions".
FACT: If you, as an author, are *mandated* either by policy or law to use
@longdesc when appropriate (and as recommended by numerous Best Practices
documents, including the W3C's own WCAG 2 Techniques document) and HTML5
simply does not have that attribute as a viable mechanism, then you cannot
use HTML5, as to do so would mean you can't use longdesc, yet the policy
says to use longdesc. Are *they* willing to stake their employment on the
logic of Jukka Korpela, or rather on what the suits say you must do?
Rhetorical question.
>
> > *EVERYONE* who has worked on this issue within the standards bodies
>
> ... must have observed how far they are from the reality. (I presume
> you
> mean real standars bodies, such as ISO and CEN, not industry consortia,
> which tend to be a little less unrealistic.)
ISO? Like ISO/IEC 15445:2000 which clearly includes the longdesc attribute
as a valid and legitimate attribute of <img> in their HTML specification?
http://www.scss.tcd.ie/misc/15445/UG.HTML#IMG
It seems as well that the ISO have a fair bit of faith in the W3C as a
Standards body:
"In January 2007, W3C became an Approved RS Originator
Organization (ARO) for ISO/JTC1. This means that ISO/JTC1 standards may
refer to W3C Recommendations 'as-is.' "
http://www.w3.org/2001/11/StdLiaison#dejure
>
> And nobody can cite an example of its being actually useful. And I mean
> the
> URL of a real web page, not a contrived and typically childish example
> of
> how it "might" be used.
I find it hard to believe that the numerous examples Laura Carlson has
compiled, such as the Public Service Commission of Canada
(http://www.psc-cfp.gc.ca/plcy-pltq/guides/structured-structuree/index-eng
.htm#fig1) the
US Department of Transportation
(http://ntl.bts.gov/lib/jpodocs/repts_pr/13669/section03.htm), or the UK
Health and Safety Executive
(http://www.hse.gov.uk/aboutus/strategiesandplans/hscplans/strategicplan01
04/plan0104-09.htm) are contrived or childish. They are real examples of
how LONDESC *is* used.
JF
From: Vlad Alexander (XStandard)
Date: Fri, Sep 24 2010 7:33PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Josh wrote: "FWIW, I think that UA support for @longdesc has been the real culprit, and not necessarily shortcomings with the attribute itself. Without some kind of breakthrough in thinking I sense we may be having this discussion again in ten years.."
Greater UA (user agent) or authoring tool support will not help with a "breakthrough in thinking". The way we define @alt and @longdesc will in the long run change authoring practices and user agent / tool support. Unfortunately, we are still talking about @alt and @longdesc as "image descriptions" with the only difference being the number of characters typed.
Jared wrote: "I've made some minor updates to our longdesc article..."
Jared, I encourage you to modify the articles on the site to describing content that appears in the @alt attribute as "textual substitute" for an image, and content appearing in the @longdesc as a "description" of the image. Please see the following for more details:
http://rebuildingtheweb.com/en/how-do-we-save-longdesc/
Regards,
-Vlad
----- Original Message -----
From: = EMAIL ADDRESS REMOVED =
To: = EMAIL ADDRESS REMOVED =
Sent: 2010-09-24T12:06:31
Subject: Re: [WebAIM] LONGDESC in HTML5?
On Fri, Sep 24, 2010 at 11:02 AM, John Foliot wrote:
> Does WebAIM believe that LONGDESC should be dropped from HTML5?
As John notes, there is much controversy surrounding the longdesc
attribute. 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.
I've made some minor updates to our longdesc article
(http://webaim.org/techniques/images/longdesc) to clarify our
recommendations for its use.
Longdesc is not an optimal approach, but it is an accepted approach
and one that is codified as an acceptable and recommended technique in
international and U.S. laws and guidelines, including Section 508 and
WCAG 2.0. While it does not have widespread use and is often misused,
obsoleting it in HTML5 is not a viable solution - and is one that
would cause confusion and result in mixed messages.
There is no question that we need better methods for providing longer
image descriptions. Like many things in accessibility, we certainly
need better support in browser and assistive technologies. The HTML5
working groups and those in the accessibility field are bright people
- the brightest of people. We're capable of coming up with something
that will work and will work better. But as of right now, longdesc
provides functionality and accessibility that is not available in any
other way. For a page that is fully accessible and compliant today to
suddenly be flagged as non-compliant and as using a non-compliant, yet
widely recommended accessibility technique simply due to transitioning
that page to an HTML5 DOCTYPE certainly goes against the
backwards-compatibility and interoperability objectives of HTML5.
Jared Smith
WebAIM
From: Joshue O Connor
Date: Sat, Sep 25 2010 2:39AM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
On 25/09/2010 02:30, Vlad Alexander (XStandard) wrote:
> Josh wrote: "FWIW, I think that UA support for @longdesc has been the real culprit,
> and not necessarily shortcomings with the attribute itself.
> Without some kind of breakthrough in thinking I sense we may be having this discussion again in ten years.."
>
> Greater UA (user agent) or authoring tool support will not help with a "breakthrough in thinking".
Actually, what I really mean is its _implementation_. The user
experience with @longdesc has been below par (even when supported). I
have a few ideas on how that could be improved which I have floated in
working group. Having said that, implementation is a vendor UA issue,
the spec can define how an element behaves but the quality of the user
experience is largely depended on how it is implemented in practice. So
FWIW, I think there is a crucial part of the jigsaw missing.
>The way we define @alt and @longdesc will in the long run change authoring practices and user agent / tool support.
Yes, ARIA 2.0 may make aria-describedby take a URI, I think this will be
a good move but again, that's down the road. The point is, the way
@longdesc is defined - is it currently more a help than a hindrance? If
it is more useful, then retain it and obsolete it when we have a better
solution. The issue of authors not using it or the shiny new thing -
will always be there.
>Unfortunately, we are still talking about @alt and @longdesc as "image descriptions" with the only difference being the number of characters typed.
What else would you like them to do? We are talking about mechanisms
that enable an equivalent user experience, any ideas to make them better
are very much appreciated.
Cheers
Josh
********************************************************************
National Council for the Blind of Ireland (NCBI) is a company
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626).
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Vlad Alexander (XStandard)
Date: Sat, Sep 25 2010 3:24AM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
I wrote: "Unfortunately, we are still talking about @alt and @longdesc as "image descriptions" with the only difference being the number of characters typed."
Josh wrote: "What else would you like them to do?"
Let's take a look at the text from this article:
http://webaim.org/techniques/images/longdesc
Article text: "In some instances, an image is too complex to describe in a few words."
The purpose of alt is not to "describe" images but to replace them. Alternate text can be quite different than a description of an image.
Article text: "Although there does not appear to be any limit to the length of text in an alt attribute, alt text is meant to be relatively short, so it would be an abuse of this attribute to write more than a few words, or, at most, a few short sentences."
Why? @alt is part of document content just like paragraphs. If you don't impose arbitrary limits on paragraphs, why impose them on alt. The author should decide on the length of alt text.
Article text: "The answer, then, is to provide a brief alt text description of the image and then provide a longer description elsewhere."
This statement implies that alt and longdesc are the same except one is longer than the other.
We need to start calling content in the @alt attribute "textual substitute" for an image, and content appearing in the @longdesc as a "description" if we ever want alt to be authored correctly and longdesc to be used.
Take care,
-Vlad
-------- Original Message --------
From: Joshue O Connor
Date: 9/25/2010 1:38 AM
> On 25/09/2010 02:30, Vlad Alexander (XStandard) wrote:
>> Josh wrote: "FWIW, I think that UA support for @longdesc has been the real culprit,
>> and not necessarily shortcomings with the attribute itself.
>> Without some kind of breakthrough in thinking I sense we may be having this discussion again in ten years.."
>>
>> Greater UA (user agent) or authoring tool support will not help with a "breakthrough in thinking".
>
> Actually, what I really mean is its _implementation_. The user
> experience with @longdesc has been below par (even when supported). I
> have a few ideas on how that could be improved which I have floated in
> working group. Having said that, implementation is a vendor UA issue,
> the spec can define how an element behaves but the quality of the user
> experience is largely depended on how it is implemented in practice. So
> FWIW, I think there is a crucial part of the jigsaw missing.
>
>> The way we define @alt and @longdesc will in the long run change authoring practices and user agent / tool support.
>
> Yes, ARIA 2.0 may make aria-describedby take a URI, I think this will be
> a good move but again, that's down the road. The point is, the way
> @longdesc is defined - is it currently more a help than a hindrance? If
> it is more useful, then retain it and obsolete it when we have a better
> solution. The issue of authors not using it or the shiny new thing -
> will always be there.
>
>> Unfortunately, we are still talking about @alt and @longdesc as "image descriptions" with the only difference being the number of characters typed.
>
> What else would you like them to do? We are talking about mechanisms
> that enable an equivalent user experience, any ideas to make them better
> are very much appreciated.
>
> Cheers
>
> Josh
>
> ********************************************************************
> National Council for the Blind of Ireland (NCBI) is a company
> limited by guarantee (registered in Ireland No. 26293) .
> Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
> NCBI is also a registered Charity (chy4626).
>
> NOTICE: The information contained in this email and any attachments
> is confidential and may be privileged. If you are not the intended
> recipient you should not use, disclose, distribute or copy any of
> the content of it or of any attachment; you are requested to notify
> the sender immediately of your receipt of the email and then to
> delete it and any attachments from your system.
>
> NCBI endeavours to ensure that emails and any attachments generated
> by its staff are free from viruses or other contaminants. However,
> it cannot accept any responsibility for any such which are
> transmitted. We therefore recommend you scan all attachments.
>
> Please note that the statements and views expressed in this email
> and any attachments are those of the author and do not necessarily
> represent the views of NCBI
>
>
> ********************************************************************
>
>
>
>
From: E.J. Zufelt
Date: Sat, Sep 25 2010 3:48AM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
On 2010-09-25, at 5:25 AM, Vlad Alexander (XStandard) wrote:
> I wrote: "Unfortunately, we are still talking about @alt and @longdesc as "image descriptions" with the only difference being the number of characters typed."
>
> Josh wrote: "What else would you like them to do?"
>
> Let's take a look at the text from this article:
> http://webaim.org/techniques/images/longdesc
>
> Article text: "In some instances, an image is too complex to describe in a few words."
>
> The purpose of alt is not to "describe" images but to replace them. Alternate text can be quite different than a description of an image.
>
> Article text: "Although there does not appear to be any limit to the length of text in an alt attribute, alt text is meant to be relatively short, so it would be an abuse of this attribute to write more than a few words, or, at most, a few short sentences."
>
> Why? @alt is part of document content just like paragraphs. If you don't impose arbitrary limits on paragraphs, why impose them on alt. The author should decide on the length of alt text.
>
> Article text: "The answer, then, is to provide a brief alt text description of the image and then provide a longer description elsewhere."
>
> This statement implies that alt and longdesc are the same except one is longer than the other.
>
> We need to start calling content in the @alt attribute "textual substitute" for an image, and content appearing in the @longdesc as a "description" if we ever want alt to be authored correctly and longdesc to be used.
>
I agree completely that we need to call content in the alt attribute ""textual substitute" in order for there to be a clear differentiation, The difference is * not * short and long description, but image replacement text and image description text.
Image description text is relative to the image, whereas image replacement text is relative to a specific usage of an image within a specific piece of content.
I think that we also need to specify that alt ought to be able to point to structured content, in case the image replacement needs to be structured text (lists, etc.).
Everett
From: Steven Faulkner
Date: Sat, Sep 25 2010 7:09AM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Hi vlad,
your wrote:
"> The purpose of alt is not to "describe" images but to replace them.
Alternate text can be quite different than a description of an image."
I cannot disagree more. the content of the alt attribute can be and is many
things:
The abscence of content indicates the image is decorative.
If the image is the sole content of a link it is a description/label of the
link target.
if the image is a photograph, diagram, illustration, cartoon, chart the alt
may be a short description of the content.
+others
I respect yours and others views, but cannot accept that it is official or
mandated anywhere that content of the alt attribute is always and can only
be a "textual substitute", nor should it be, just as it should not be
mandated that the presence of the image object in a HTML page must not be
conveyed to users.
regards
stevef
On 25 September 2010 10:42, E.J. Zufelt < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 2010-09-25, at 5:25 AM, Vlad Alexander (XStandard) wrote:
>
> > I wrote: "Unfortunately, we are still talking about @alt and @longdesc as
> "image descriptions" with the only difference being the number of characters
> typed."
> >
> > Josh wrote: "What else would you like them to do?"
> >
> > Let's take a look at the text from this article:
> > http://webaim.org/techniques/images/longdesc
> >
> > Article text: "In some instances, an image is too complex to describe in
> a few words."
> >
> > The purpose of alt is not to "describe" images but to replace them.
> Alternate text can be quite different than a description of an image.
> >
> > Article text: "Although there does not appear to be any limit to the
> length of text in an alt attribute, alt text is meant to be relatively
> short, so it would be an abuse of this attribute to write more than a few
> words, or, at most, a few short sentences."
> >
> > Why? @alt is part of document content just like paragraphs. If you don't
> impose arbitrary limits on paragraphs, why impose them on alt. The author
> should decide on the length of alt text.
> >
> > Article text: "The answer, then, is to provide a brief alt text
> description of the image and then provide a longer description elsewhere."
> >
> > This statement implies that alt and longdesc are the same except one is
> longer than the other.
> >
> > We need to start calling content in the @alt attribute "textual
> substitute" for an image, and content appearing in the @longdesc as a
> "description" if we ever want alt to be authored correctly and longdesc to
> be used.
> >
> I agree completely that we need to call content in the alt attribute
> ""textual substitute" in order for there to be a clear differentiation, The
> difference is * not * short and long description, but image replacement text
> and image description text.
>
> Image description text is relative to the image, whereas image replacement
> text is relative to a specific usage of an image within a specific piece of
> content.
>
> I think that we also need to specify that alt ought to be able to point to
> structured content, in case the image replacement needs to be structured
> text (lists, etc.).
>
>
> Everett
>
From: Duff Johnson
Date: Sat, Sep 25 2010 8:36AM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
On Sep 25, 2010, at 9:08 AM, Steven Faulkner wrote:
> I cannot disagree more. the content of the alt attribute can be and is many
> things:
First, I'm going to associate myself in general with Steve's remarks - well put, and as such, unarguable.
I want to offer comment on a couple items and offer a point of information from the PDF world to see if it resonates.
> The abscence of content indicates the image is decorative.
In PDF, if we consider that a graphical object is "decorative" and thus, not part of the semantic content, we mark it as "artifact" at which point it (logically) disappears - ie, it won't appear in the DOM, so AT can't "see" it. Problem solved.
> if the image is a photograph, diagram, illustration, cartoon, chart the alt
> may be a short description of the content.
Likewise in PDF. However, PDF adds the possibility of explicitly identifying the content of an image as a representation of text. This is especially handy for ligatures, for example, and obviously, many documents use this sort of thing for section headings.
The question of "replacement" vs. "description" is resolved by one's choosing to use the "Actual Text" attribute of the image's corresponding Figure tag.
In practice, the use of the Actual Text attribute should be interpreted by AT as meaning that there's no actual "image" present (logically) at all, and thus the value of the attribute is to be treated as inline text, without announcing the fact of the image at all.
In all other cases (ie, where we use the alt. text attribute) the valid (we think) processing is to announce the fact of the image, followed by the alt. text.
> +others
Indeed.
In our world, content "is" what the author intends, period. I'd like to hear the "best available" case for eliminating longdesc - I'm unimpressed by what I've heard so far. I can think of number of use-cases in which a short vs. long (for example, literal) description of an image would be a service to the end-user.
PDF has no "longdesc" attribute right now - more's the pity. Perhaps we should put it in for 32000-2? Please let me know what you think - I need to get final comments into the draft very soon!
Duff Johnson
Appligent Document Solutions, CEO
US Committee for ISO/CD 14289 (PDF/UA), Chair
US Committee for ISO 32000 (PDF/Reference), Vice Chair
US Committee for ISO 19005 (PDF/A), Member
PDF/A Competence Center North American Chapter, Chair
22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
= EMAIL ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson
From: Vlad Alexander (XStandard)
Date: Sat, Sep 25 2010 10:42AM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Steve wrote: "I cannot disagree more. the content of the alt attribute can be and is many things"
I don't see that. It's a really simple concept and if we keep it simple, people will then use it correctly.
Please don't take this personally (this is professional feedback), but I feel you are making alt more complex than necessary. Your 40+ page document on how to write alt text in HTML5 is way too complex and will unfortunately serve the purpose (directly or through derivative works) of scaring content authors/developers/tool vendors so that they will simply ignore alt or give it cursorily effort.
http://dev.w3.org/html5/alt-techniques/
Steve wrote: "The abscence of content indicates the image is decorative."
That fits with the definition of alt as a textual replacement for an image. In this case, the replacement text is blank because it is unnecessary given surrounding content.
Steve wrote: "If the image is the sole content of a link it is a description/label of the link target."
Let's put this to a test.
Test 1: In this case, should the author write alt to fit the target of the link or to fit surrounding content? I would argue that you should be able to add or remove a hyperlink from a document withing affecting the comprehension of that document. In other words, if I want to add or remove a hyperlink, I should not have to re-write content in the document. The only way to achieve this is to write content (be it normal text or alt text) to fit surrounding content.
Test 2: Paste the document into plain text such as Notepad or plain text email. Hyperlinks are removed. You are left with document content. So if alt is a "description/label of the link target" it's pretty useless here.
Steve wrote: "if the image is a photograph, diagram, illustration, cartoon, chart the alt may be a short description of the content."
That fits with the definition of alt as a textual replacement for an image. It all depends on the context (surrounding text). At this link I provide examples where alt is not a short description of a chart but instead text that is a substitute for an image to make surrounding context comprehensible.
http://rebuildingtheweb.com/en/how-do-we-save-longdesc/#c20100824114946
Take care,
-Vlad
-------- Original Message --------
From: Steven Faulkner
Date: 9/25/2010 6:08 AM
> Hi vlad,
>
> your wrote:
> "> The purpose of alt is not to "describe" images but to replace them.
> Alternate text can be quite different than a description of an image."
>
> I cannot disagree more. the content of the alt attribute can be and is many
> things:
> The abscence of content indicates the image is decorative.
> If the image is the sole content of a link it is a description/label of the
> link target.
> if the image is a photograph, diagram, illustration, cartoon, chart the alt
> may be a short description of the content.
> +others
>
> I respect yours and others views, but cannot accept that it is official or
> mandated anywhere that content of the alt attribute is always and can only
> be a "textual substitute", nor should it be, just as it should not be
> mandated that the presence of the image object in a HTML page must not be
> conveyed to users.
>
> regards
> stevef
>
>
>
> On 25 September 2010 10:42, E.J. Zufelt< = EMAIL ADDRESS REMOVED = > wrote:
>
>>
>> On 2010-09-25, at 5:25 AM, Vlad Alexander (XStandard) wrote:
>>
>>> I wrote: "Unfortunately, we are still talking about @alt and @longdesc as
>> "image descriptions" with the only difference being the number of characters
>> typed."
>>>
>>> Josh wrote: "What else would you like them to do?"
>>>
>>> Let's take a look at the text from this article:
>>> http://webaim.org/techniques/images/longdesc
>>>
>>> Article text: "In some instances, an image is too complex to describe in
>> a few words."
>>>
>>> The purpose of alt is not to "describe" images but to replace them.
>> Alternate text can be quite different than a description of an image.
>>>
>>> Article text: "Although there does not appear to be any limit to the
>> length of text in an alt attribute, alt text is meant to be relatively
>> short, so it would be an abuse of this attribute to write more than a few
>> words, or, at most, a few short sentences."
>>>
>>> Why? @alt is part of document content just like paragraphs. If you don't
>> impose arbitrary limits on paragraphs, why impose them on alt. The author
>> should decide on the length of alt text.
>>>
>>> Article text: "The answer, then, is to provide a brief alt text
>> description of the image and then provide a longer description elsewhere."
>>>
>>> This statement implies that alt and longdesc are the same except one is
>> longer than the other.
>>>
>>> We need to start calling content in the @alt attribute "textual
>> substitute" for an image, and content appearing in the @longdesc as a
>> "description" if we ever want alt to be authored correctly and longdesc to
>> be used.
>>>
>> I agree completely that we need to call content in the alt attribute
>> ""textual substitute" in order for there to be a clear differentiation, The
>> difference is * not * short and long description, but image replacement text
>> and image description text.
>>
>> Image description text is relative to the image, whereas image replacement
>> text is relative to a specific usage of an image within a specific piece of
>> content.
>>
>> I think that we also need to specify that alt ought to be able to point to
>> structured content, in case the image replacement needs to be structured
>> text (lists, etc.).
>>
>>
>> Everett
>>
From: Jukka K. Korpela
Date: Sat, Sep 25 2010 12:48PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
John Foliot wrote:
> The simple fact of the matter is that while adoption has been slow,
> there are numerous cases of its usage, and documented existence of
> laws, policies and guidelines that suggest your current opinion is
> not correct. (http://www.d.umn.edu/~lcarlson/research/ld.html#glps)
You are citing a document titled "Guidelines, Laws, Policy, and Standards",
though it contains some links to actual usage. Let's pick up one:
http://cirrie.buffalo.edu/encyclopedia/article.php?id=108&;language=en#s7
There we have a figure with a longdesc attribute, followed by a link to the
same plain text document as referred to by the attribute.
So what is the point of the attribute? It only creates unnecessary
duplication for those users who notice it - they will have to guess or
check, by comparing the URLs, whether the resources are identical.
In short, the longdesc attribute just creates confusion. And if the link
were _not_ there, all people who do not notice the attribute, for some
reason or another, such as due to using a browser that ignores it, would not
have access to the text description.
> Removing the existing @longdesc attribute from HTML5 breaks the basic
> premise of HTML5 being backward compatible,
There's a large number of well-established HTML features that are banned in
HTML 5, in the sense that the draft says that authors must not use them. Of
course this is just a verbal game. Browsers will keep supporting what they
have supported (they just have to), and authors will keep using banner
features if they like, especially since HTML 5 says that browser must
support them. Making longdesc banned (using whatever verbal acrobacy that
HTML 5 will exercise to avoid saying "banned" or "deprecated") will have
some effect, admittedly: browser vendors will have less reasons to _add_
support to browsers that now lack it. And that's fine. They have better
things to do.
> and for those who *must*
> use @longdesc due to their workplace requirements, it effectively
> means that they cannot move towards using HTML5.
That's just fine. There is no reason to think that you can move forward
_and_ keep using outdated constructs. If the workplace requirements are
outdated, they need to be fixed, instead of adding outdated ideas to new
drafts.
> Nothing you can say
> or argue removes this fundamental fact.
Even if your statement were correct, it would not be a _fact_ any more than
my correct statement is a fact. Facts are simple statements about observable
phenomena. Principles, even well-founded principles, are not facts.
> @longdesc fills a need, one that is not met by any other native
> semantic means.
Which specific need does it fill, considering the existence of links in HTML
since the early days? Longdesc is effectively a hidden link with very
limited browser support (limited to specialized browsing software, as
opposite to normal graphic browsers). What's the need for hiding a link?
I could imagine some _use_, though not compelling need, for a construct like
<figure>
<img ...>
<longdesc>An <a href="...">explanation of figure 1</a> is
available.</longdesc>
</figure>
... so that a browser not supporting <longdesc> (in some way which we might
expect to be advanced and suitable for the specific way of browsing with it)
would simply ignore the tags and fall back to rendering its content.
> Seeking to keep a rich and useful toolkit to improve accessibility is
> not a waste of anyone's time,
It is, if some of the tools are quite unsuitable for the intended use.
Whatever time spent in writing longdesc attributes is better spent doing
something useful.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: Steven Faulkner
Date: Sat, Sep 25 2010 1:00PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
hi Vlad,
>I don't see that. It's a really simple concept and if we keep it simple,
people will then use it correctly.
I have never seen an understandable explanation of this 'really simple
concept' that covers the many ways images are used on the web.
>Please don't take this personally (this is professional feedback), but I
feel you are making alt more complex than necessary. Your 40+ page document
on how to >write alt text in HTML5 is way too complex and will unfortunately
serve the purpose (directly or through derivative works) of scaring content
>authors/developers/tool vendors so that they will simply ignore alt or give
it cursorily effort.
I won't take it personally as I am only the editor of the draft
specification (http://dev.w3.org/html5/alt-techniques/) not the author.
IThere hasn't been any feedback apart from yours that it is too complex and
will scare content authors. It is aimed at authors not tool vendors, they
will find the HTML5 spec itself much more useful. Its is a collaboritve work
being developed by the W3C HTML working group. It attempts to cover all
methods for providing text alternatives for images, not only the use of the
alt attribute. It provides many examples as there are many ways in which
images are used.
As I have written previously, If you wish to make comments regarding this
document, please send them to = EMAIL ADDRESS REMOVED =
(subscribe< = EMAIL ADDRESS REMOVED = ?subject=subscribe>,
archives <http://lists.w3.org/Archives/Public/public-html-comments/>;) or
submit them using the W3C public bug
database<http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&;component=alt%20techniques%20(editor:%20Steven%20Faulkner)>.
All feedback is welcome. If you can find the time to provide constructive
comments on how the document can be simplified without losing importnat
information it would be much appreciated.
>That fits with the definition of alt as a textual replacement for an image.
But the content of alt is not defined as a 'textual replacement' it is
defined as a 'text alternative'. At times it makes sense for text
alternatives to be textual replacements at other times it does not.
>Test 1: ...I would argue that you should be able to add or remove a
hyperlink from a document withing affecting the comprehension of that
document.
example:
This is an <a href="inline-definition.html">inline link</a>.
take away the link:
This is an inline link.
meaning and functionality is lost.
>Test 2: Paste the document into plain text such as Notepad or plain text
email. Hyperlinks are removed. You are left with document content. So if alt
is a "description/label of the link target" it's pretty useless here.
the same can be said for any interactive and non text objects
here is a list of links lifted form the MLB site:
Scoreboard Standings Schedule Stats Players News Video
pretty useless aren't they? that is because they are not meant to be viewed
as plain text they are made useful by their functionality (hyperlinks) they
label.
>At this link I provide examples where alt is not a short description of a
chart but instead text that is a substitute for an image to make surrounding
context comprehensible.
The issue is that you (vlad) always put an image in in the context as part
of a narrative, yes images are sometimes used like that, but often times
they are not, and when they are not, either your method fails to be useful
or you recast every instance of image use to fit your method, neither are
desirable or practical outcomes.
regards
Stevef
On 25 September 2010 17:44, Vlad Alexander < = EMAIL ADDRESS REMOVED = >wrote:
> Steve wrote: "I cannot disagree more. the content of the alt attribute can
> be and is many things"
>
> I don't see that. It's a really simple concept and if we keep it simple,
> people will then use it correctly.
>
> Please don't take this personally (this is professional feedback), but I
> feel you are making alt more complex than necessary. Your 40+ page document
> on how to write alt text in HTML5 is way too complex and will unfortunately
> serve the purpose (directly or through derivative works) of scaring content
> authors/developers/tool vendors so that they will simply ignore alt or give
> it cursorily effort.
>
> http://dev.w3.org/html5/alt-techniques/
>
> Steve wrote: "The abscence of content indicates the image is decorative."
>
> That fits with the definition of alt as a textual replacement for an image.
> In this case, the replacement text is blank because it is unnecessary given
> surrounding content.
>
> Steve wrote: "If the image is the sole content of a link it is a
> description/label of the link target."
>
> Let's put this to a test.
>
> Test 1: In this case, should the author write alt to fit the target of the
> link or to fit surrounding content? I would argue that you should be able to
> add or remove a hyperlink from a document withing affecting the
> comprehension of that document. In other words, if I want to add or remove a
> hyperlink, I should not have to re-write content in the document. The only
> way to achieve this is to write content (be it normal text or alt text) to
> fit surrounding content.
>
> Test 2: Paste the document into plain text such as Notepad or plain text
> email. Hyperlinks are removed. You are left with document content. So if alt
> is a "description/label of the link target" it's pretty useless here.
>
> Steve wrote: "if the image is a photograph, diagram, illustration, cartoon,
> chart the alt may be a short description of the content."
>
> That fits with the definition of alt as a textual replacement for an image.
> It all depends on the context (surrounding text). At this link I provide
> examples where alt is not a short description of a chart but instead text
> that is a substitute for an image to make surrounding context
> comprehensible.
>
> http://rebuildingtheweb.com/en/how-do-we-save-longdesc/#c20100824114946
>
> Take care,
> -Vlad
>
>
> -------- Original Message --------
> From: Steven Faulkner
> Date: 9/25/2010 6:08 AM
> > Hi vlad,
> >
> > your wrote:
> > "> The purpose of alt is not to "describe" images but to replace them.
> > Alternate text can be quite different than a description of an image."
> >
> > I cannot disagree more. the content of the alt attribute can be and is
> many
> > things:
> > The abscence of content indicates the image is decorative.
> > If the image is the sole content of a link it is a description/label of
> the
> > link target.
> > if the image is a photograph, diagram, illustration, cartoon, chart the
> alt
> > may be a short description of the content.
> > +others
> >
> > I respect yours and others views, but cannot accept that it is official
> or
> > mandated anywhere that content of the alt attribute is always and can
> only
> > be a "textual substitute", nor should it be, just as it should not be
> > mandated that the presence of the image object in a HTML page must not be
> > conveyed to users.
> >
> > regards
> > stevef
> >
> >
> >
> > On 25 September 2010 10:42, E.J. Zufelt< = EMAIL ADDRESS REMOVED = > wrote:
> >
> >>
> >> On 2010-09-25, at 5:25 AM, Vlad Alexander (XStandard) wrote:
> >>
> >>> I wrote: "Unfortunately, we are still talking about @alt and @longdesc
> as
> >> "image descriptions" with the only difference being the number of
> characters
> >> typed."
> >>>
> >>> Josh wrote: "What else would you like them to do?"
> >>>
> >>> Let's take a look at the text from this article:
> >>> http://webaim.org/techniques/images/longdesc
> >>>
> >>> Article text: "In some instances, an image is too complex to describe
> in
> >> a few words."
> >>>
> >>> The purpose of alt is not to "describe" images but to replace them.
> >> Alternate text can be quite different than a description of an image.
> >>>
> >>> Article text: "Although there does not appear to be any limit to the
> >> length of text in an alt attribute, alt text is meant to be relatively
> >> short, so it would be an abuse of this attribute to write more than a
> few
> >> words, or, at most, a few short sentences."
> >>>
> >>> Why? @alt is part of document content just like paragraphs. If you
> don't
> >> impose arbitrary limits on paragraphs, why impose them on alt. The
> author
> >> should decide on the length of alt text.
> >>>
> >>> Article text: "The answer, then, is to provide a brief alt text
> >> description of the image and then provide a longer description
> elsewhere."
> >>>
> >>> This statement implies that alt and longdesc are the same except one is
> >> longer than the other.
> >>>
> >>> We need to start calling content in the @alt attribute "textual
> >> substitute" for an image, and content appearing in the @longdesc as a
> >> "description" if we ever want alt to be authored correctly and longdesc
> to
> >> be used.
> >>>
> >> I agree completely that we need to call content in the alt attribute
> >> ""textual substitute" in order for there to be a clear differentiation,
> The
> >> difference is * not * short and long description, but image replacement
> text
> >> and image description text.
> >>
> >> Image description text is relative to the image, whereas image
> replacement
> >> text is relative to a specific usage of an image within a specific piece
> of
> >> content.
> >>
> >> I think that we also need to specify that alt ought to be able to point
> to
> >> structured content, in case the image replacement needs to be structured
> >> text (lists, etc.).
> >>
> >>
> >> Everett
> >>
From: Jukka K. Korpela
Date: Sat, Sep 25 2010 1:30PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Vlad Alexander (XStandard) wrote:
> Steve wrote: "I cannot disagree more. the content of the alt
> attribute can be and is many things"
>
> I don't see that. It's a really simple concept and if we keep it
> simple, people will then use it correctly.
The alt attribute has been defined in a simple manner, though with some
contradictions (calling it both "replacement" and "description"), but this
has not made people use it correctly.
There are many cases where it is very obvious what the alt text should be -
though authors often omit alt attributes or write something nonsensical in
them.
The problems start when no single word and no short phrase, or even a
paragraph, can act as an adequate replacement for the image. If the image is
a complex graph, or an artistic painting, or a photograph of a person, then
it should be obvios that _no_ text can be an adequate replacement. It's not
about alt, it's not about longdesc, it's about images.
A document containing an image that is _inherently_ visual content - as
opposite to a decorative ornament or styled text, for example - should at
least inform a user who does not see the image about this. It's all wrong to
provide some textual replacement or explanation or annotation as if it told
the whole story (like simple alt texts for simple images often can tell,
e.g. when the image is just text in image format).
> Steve wrote: "if the image is a photograph, diagram, illustration,
> cartoon, chart the alt may be a short description of the content."
>
> That fits with the definition of alt as a textual replacement for an
> image.
No it does not. If you think it is, you are obscuring the role of alt texts
that really act as replacements. An image button with text "Go" in it has
the textual replacement "Go", undoubtedly. But if you have a photograph of a
house and you write alt="photo of a house" (or alt="(photo of a house)",
which I would prefer), you are not writing an adequate replacement - just
giving a hint. (It's no more a replacement than the words "A poem" would
constitute a replacement for a poem.) In practice, such alt texts are
usually the best we can do, even though it does not conform to the simple
idea of alt as replacement.
If the photo is relevant content, as opposite to mere decoration or
mood-creation, then you might write a long passage of text explaining what's
in the image, mentioning the features of the house and the surroundings that
are relevant. But that's really a matter of content creation. In effect, you
would be creating textual content that is somehow _parallel_ or
_alternative_ to the image. It might say a lot less, but also a lot more.
The image itself would not say what is relevant in it; the text might
concentrate on features that are meant to be essential but are missed by
someone who only sees the image.
If parallel or alternative textual content is created, then it would be all
wrong to use alt or longdesc for them. Instead, graphic and textual content
should both be presented in some manner that makes it easy to understand
their relationships and to access either or both of them
> It all depends on the context (surrounding text). At this link
> I provide examples where alt is not a short description of a chart
> but instead text that is a substitute for an image to make
> surrounding context comprehensible.
>
> http://rebuildingtheweb.com/en/how-do-we-save-longdesc/#c20100824114946
That's a good example of parallel or alternative content: a graph versus a
table. It's often a good idea to provide both, because people may prefer one
or the other (or both). It's counter-productive to hide the table behind a
faulty plastic imitation of a link, i.e. the longdesc attribute. Instead,
the author should decide which presentation is primary (and provide a
normal, descriptively written link to the other), or maybe include both of
them in the flow of normal content.
(In general, a table of data and a graph of the "same" data does not have
exactly the same content. A graph tends to have less details and less
accuracy. This is no problem if you think of them as a parallel
presentations, but it becomes a problem if you want to present one of them
as a replacement or description of the other.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: Vlad Alexander (XStandard)
Date: Sat, Sep 25 2010 1:39PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Steve wrote: "But the content of alt is not defined as a 'textual replacement' it is
defined as a 'text alternative'."
What does 'text alternative' mean to you?
Steve wrote: "At times it makes sense for text alternatives to be textual replacements at other times it does not."
Please provide examples.
Steve wrote:
--- start ---
This is an <a href="inline-definition.html">inline link</a>.
take away the link:
This is an inline link.
meaning and functionality is lost.
--- end ---
Your example is very similar to "click here" example. This is bad writing for the Web. A better way to write this is:
An <a href="inline-definition.html">inline link</a> is used for ....
Steve wrote:
--- start ---
the same can be said for any interactive and non text objects
here is a list of links lifted form the MLB site:
Scoreboard Standings Schedule Stats Players News Video
--- end ---
Actually, that is not what gets pasted into Notepad. When you paste into Notepad you get the following which is easy to read and can be quite useful:
MLB.com
mlb.jp
LasMayores.com
www.mlb.cn
www.mlbkorea.com
Low Bandwidth Site
Register
My MLB.com (Login)
Fan Forum
Search Go
Top Searches:
Lincecum
Phillies
A-Rod
Postseason
MLB Sites
Scoreboard
Standings
Schedule
Stats
Players
News
Video
Tickets
Mobile
Shop
Auction
Fantasy
Steve wrote: "The issue is that you (vlad) always put an image in in the context as part
of a narrative"
Isn't that how images are supposed to be used?
Steve wrote: "...yes images are sometimes used like that, but often times
they are not"
Please provide mainstream and best practice examples to demonstrate your point.
Take care,
-Vlad
From: Steven Faulkner
Date: Sat, Sep 25 2010 1:54PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Hi Vlad,
>Please provide examples.
there are examples here: http://dev.w3.org/html5/alt-techniques/
regards
Stevef
On 25 September 2010 20:38, Vlad Alexander < = EMAIL ADDRESS REMOVED = >wrote:
> Steve wrote: "But the content of alt is not defined as a 'textual
> replacement' it is
> defined as a 'text alternative'."
>
> What does 'text alternative' mean to you?
>
> Steve wrote: "At times it makes sense for text alternatives to be textual
> replacements at other times it does not."
>
> Please provide examples.
>
> Steve wrote:
> --- start ---
> This is an <a href="inline-definition.html">inline link</a>.
>
> take away the link:
>
> This is an inline link.
>
> meaning and functionality is lost.
> --- end ---
>
> Your example is very similar to "click here" example. This is bad writing
> for the Web. A better way to write this is:
>
> An <a href="inline-definition.html">inline link</a> is used for ....
>
> Steve wrote:
> --- start ---
> the same can be said for any interactive and non text objects
>
> here is a list of links lifted form the MLB site:
>
> Scoreboard Standings Schedule Stats Players News Video
> --- end ---
>
> Actually, that is not what gets pasted into Notepad. When you paste into
> Notepad you get the following which is easy to read and can be quite useful:
>
> MLB.com
>
> mlb.jp
> LasMayores.com
> www.mlb.cn
> www.mlbkorea.com
>
> Low Bandwidth Site
>
> Register
> My MLB.com (Login)
>
> Fan Forum
> Search Go
>
> Top Searches:
> Lincecum
> Phillies
> A-Rod
>
> Postseason
>
> MLB Sites
> Scoreboard
> Standings
> Schedule
> Stats
> Players
> News
> Video
> Tickets
> Mobile
> Shop
> Auction
> Fantasy
>
>
> Steve wrote: "The issue is that you (vlad) always put an image in in the
> context as part
> of a narrative"
>
> Isn't that how images are supposed to be used?
>
> Steve wrote: "...yes images are sometimes used like that, but often times
> they are not"
>
> Please provide mainstream and best practice examples to demonstrate your
> point.
>
> Take care,
> -Vlad
>
>
>
>
>
From: Vlad Alexander (XStandard)
Date: Sat, Sep 25 2010 2:12PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Jukka, wrote: "The problems start when no single word and no short phrase, or even a paragraph, can act as an adequate replacement for the image."
Although you are using the word "adequate", from your other comments, I believe you are saying that textual content cannot be an "equal" replacement for visual content. Nobody is disputing that textual content is not "equal" to visual content. But that is not the goal. The objective is to make textual content "equivalent" in meaning/purpose to visual content and vise-versa. Nobody is seeking perfection. The goal is to have a technology that provides comprehensible content to as many people as possible and to machines.
Take care,
-Vlad
From: John Foliot
Date: Sat, Sep 25 2010 2:24PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Vlad Alexander (XStandard) wrote:
>
> Steve wrote: "I cannot disagree more. the content of the alt attribute
> can be and is many things"
>
> I don't see that. It's a really simple concept and if we keep it
> simple, people will then use it correctly.
There is simple, and then there is simplistic.
Like most of what we try to evaluate when we do our 'accessibility
reviews', determination of appropriate alt text is both subjective and
relative: an image can and does serve many different purposes in a
document, thus the alt text *should* be flexible enough to address those
issues. Applying simplistic rules does nothing to enhance or even support
user experience.
What is really important (to me) to understand is that, especially for
screen reading technology (and yes, I've been doing this long enough to
know that accessibility is more than just screen readers) - for screen
readers the user experience is as important a consideration as anything
else.
Thus, Vlad's recommendation becomes at times overly simplistic, as he is
removing the contextual piece of the user experience.
> Vlad wrote:
>
> Let's put this to a test.
>
> Test 1: In this case, should the author write alt to fit the target of
> the link or to fit surrounding content? I would argue that you should
> be able to add or remove a hyperlink from a document without affecting
> the comprehension of that document.
Steven Faulkner wrote:
>
> The issue is that you (vlad) always put an image in in the context as
> part of a narrative, yes images are sometimes used like that, but often
> times they are not, and when they are not, either your method fails to
be
> useful or you recast every instance of image use to fit your method,
neither
> are desirable or practical outcomes.
+1 to Steven.
Even when images are part of the narrative, again understanding the user
experience is required to determine useful alt text. I offer as an
example, the following image:
http://www.happywebbies.com/products/holzschlag.png
Many of us know and love Molly Holzschlag, and likely many of us too would
recognize this image of her. But what is the appropriate alt text for that
image?
Alt="Molly Holzschlag"
Alt="caricature of Molly Holzschlag"
Is the fact that it is a caricature of Molly (as opposed to an actual
photograph) important information to convey? (I argue yes). Thus the alt
text is more than just a textual replacement, as the alt text also
provides some descriptive context (it is a caricature).
However if I were to use that image as a link to the corresponding web
page where I can purchase a T-shirt with that image on it, then what would
the alt text be? Does this really make sense?
"Link: caricature of Molly Holzschlag"
(<a href="
http://www.happywebbies.com/store/detail/molly-holzschlag/"><img
src="http://www.happywebbies.com/products/holzschlag.png" alt="caricature
of Molly Holzschlag" /></a>)
Context is everything!
Vlad wrote:
> In other words, if I want to add or
> remove a hyperlink, I should not have to re-write content in the
> document. The only way to achieve this is to write content (be it
> normal text or alt text) to fit surrounding content.
I think that this is somewhat of a Straw-man argument. Web pages are not
documents in the same sense that PDFs or Word Docs are documents: they are
a type of document unto themselves, as they also include the interactivity
of hypertext links.
As such, they should be authored to be what they are, not what they might
be re-purposed to be. Suggesting otherwise (I argue) can actually degrade
the user experience of non-sighted users.
>
> Test 2: Paste the document into plain text such as Notepad or plain
> text email. Hyperlinks are removed. You are left with document content.
> So if alt is a "description/label of the link target" it's pretty
> useless here.
Omitting the fact that the image provides a link to a secondary document
(web-page) makes the advisory that an image exists somewhat useless as
well. At that point is simply becomes extraneous text, with little to no
actual usefulness to the reader (sighted or otherwise).
>
> That fits with the definition of alt as a textual replacement for an
> image. It all depends on the context (surrounding text).
"Context" with regard to web content is simply more than the sum of text
on the page; without addressing the fact that there is some interaction
associated to an image, you are not conveying the full context of the
image, nor the document that contains that image.
(As an interesting example of the concept of retaining links with web
documents - and to refute Vlad's Straw-man argument - visit a Wikimedia
page such as:
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist, and then
from your browser look at the "Print Preview")
<aside>
Jukka K. Korpela wrote:
>
> But if you have a photograph of a
> house and you write alt="photo of a house" (or alt="(photo of a
> house)", which I would prefer)
I have also suggested a similar design pattern: alt="[photo of a house]",
the advantage being that square brackets are less used for other contexts,
and as they are unusual punctuation in the traditional sense, most screen
readers will omit announcing the square brackets (unless the verbosity
level is set to high) - I do this again with an eye/ear towards best user
experience.
</aside>
JF
From: Vlad Alexander (XStandard)
Date: Sat, Sep 25 2010 4:00PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
John wrote: "There is simple, and then there is simplistic."
John, please provide mainstream and best practice examples where the rule I propose to author alt text fails and hinders comprehension. And let's put the examples right in this thread. Here is the rule I propose. Alternate text is a textual substitute for an image and appropriate alternate text can only be authored by taking into consideration its context (content preceding and following the image).
John wrote: "As such, they [Web pages] should be authored to be what they are, not what they might be re-purposed to be. Suggesting otherwise (I argue) can actually degrade the user experience of non-sighted users."
It's not just about re-purposing content. It's about recognizing that the Web is made up of more than just graphical Web browsers with AT being dependent and sitting on top of these browsers. Large consumers of Web content are applications (machines) that can only view the Web as textual content.
Take care,
-Vlad
From: Jukka K. Korpela
Date: Sat, Sep 25 2010 4:06PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Vlad Alexander (XStandard) wrote:
> Jukka, wrote: "The problems start when no single word and no short
> phrase, or even a paragraph, can act as an adequate replacement for
> the image."
>
> Although you are using the word "adequate", from your other comments,
> I believe you are saying that textual content cannot be an "equal"
> replacement for visual content.
No, I mean equivalent, or reasonably close to equivalent.
> The objective is to make textual content "equivalent" in
> meaning/purpose to visual content and vise-versa.
If you take a normal photo, then there is no equivalent, or even close to
equivalent, text. So the objective is mission impossible, and we need to
consider something more realistic.
> Nobody is seeking perfection.
What?? I am. But perfection, and even imperfect success, turns out to be
impossible at times. The requirement that every image have an alt attribute
specifying a textual replacement for the image is one of the cases. For some
images, the requirement is very easy to fulfill; for some rare cases, it is
difficult but possible; and for many images, it simply isn't possible. It's
time to admit this and draw the conclusions. And it does not depend on some
assumed length limitations or anything that technical.
> The goal is to have a technology that provides
> comprehensible content to as many people as possible and to machines.
Being comprehensible isn't enough. You can't just put _any_ comprehensible
content in an alt attribute, for example. It needs to say the same thing as
the image, or clearly indicate that it does not do that but just gives a
hint, or description, instead.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: Joshue O Connor
Date: Sat, Sep 25 2010 4:18PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
On 25/09/2010 17:44, Vlad Alexander (XStandard) wrote:
> Steve wrote: "I cannot disagree more. the content of the alt attribute can be and is many things"
>
> I don't see that. It's a really simple concept and if we keep it simple, people will then use it correctly.
It's not that simple. In particular when you consider the many ways
developers have of using HTML, as Steve mentioned the basic example of
using images as buttons etc so the @alt must practically refer to
function rather than form for that use case to be accessible. The
semantic toolkit is expanding for sure, but the notion of "lets define
the spec this way, and authors will conform" ain't the way the wild is.
Josh
********************************************************************
National Council for the Blind of Ireland (NCBI) is a company
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626).
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: John Foliot
Date: Sat, Sep 25 2010 4:24PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Vlad Alexander (XStandard) wrote:
>
> Here is the rule I
> propose. Alternate text is a textual substitute for an image and
> appropriate alternate text can only be authored by taking into
> consideration its context (content preceding and following the image).
Note, I don't necessarily agree with the current alt text on these pages,
but please Vlad, apply your rule to this page's images:
http://www.happywebbies.com/
or this one:
http://www.zinkwazi.com/scripts/demo/phpslideshow.php?directory=photos
Context, yes, but not as a print document. Continuing to use that paradigm
is simply wrong.
>
> John wrote: "As such, they [Web pages] should be authored to be what
> they are, not what they might be re-purposed to be. Suggesting
> otherwise (I argue) can actually degrade the user experience of non-
> sighted users."
>
> It's not just about re-purposing content. It's about recognizing that
> the Web is made up of more than just graphical Web browsers with AT
> being dependent and sitting on top of these browsers. Large consumers
> of Web content are applications (machines) that can only view the Web
> as textual content.
Such as...?
Web-based "machines" (applications) such as Search Engines process 'pages'
in their entirety and capture link associations at the same time. Please
name one web-based "machine" that only processes text, and does not
process hyperlinks at the same time.
JF
From: Vlad Alexander (XStandard)
Date: Sat, Sep 25 2010 5:33PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
John wrote:
--- start ---
Note, I don't necessarily agree with the current alt text on these pages, but please Vlad, apply your rule to this page's images:
http://www.happywebbies.com/
--- end ---
I would not change the alt text for each image, instead I would change the images. I would put the name of each person in the image and I would put the purpose of the site/page at the top. This is a usability issue. As a sighted user I have no idea what this site does nor who those people are. John, if you are going to provide an example, please provide a best practice example that invalidates the rule I am proposing. Unless you are suggesting specifications and derivative works should teach users to write appropriate alt text for badly constructed Web pages.
Regarding this photo site:
http://www.zinkwazi.com/scripts/demo/phpslideshow.php?directory=photos
Photos on photo sharing sites should have blank alt text. Instead, there should be a caption or label that is accessible to all visitors. Please see this:
http://rebuildingtheweb.com/en/no-alt-text-for-photo-sharing-sites/
John wrote: "Please name one web-based 'machine' that only processes text, and does not process hyperlinks at the same time."
Do you mean strip out the hyperlink when processing the content for a given purpose or when presenting that content to a user? Google does that. For example, here is one search result for search on longdesc:
--- start ---
22 Aug 2010 ... How do we save longdesc ? The longdesc attribute, although potentially useful, was removed from the HTML5 specification, ...
--- end ---
In the above, Google striped out the hyperlink around the text "How do we save longdesc ?"
Take care,
-Vlad
From: John Foliot
Date: Sat, Sep 25 2010 7:00PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Vlad Alexander (XStandard) wrote
>
>
> I would not change the alt text for each image, instead I would change
> the images.
It doesn't work that way Vlad.
> I would put the name of each person in the image and I
> would put the purpose of the site/page at the top. This is a usability
> issue.
We simply are not going to change the way the web evolved Vlad, no matter
how much we want to. You talk to me like I'm some wet-behind-the-ears kid
who has no clue, and I find that offensive.
I presented you with two real-world sites that have real-world problems,
and rather than address solving the problems, you espouse how you would do
it differently. That's not your call to make.
Both of those examples also invalidate "*your* rule", because your rule
assumes that images are always part of a document narrative, and both of
those sites/pages are not about document narratives - their sole purpose
is to render images. You can stand on the sidelines and wave your hands
all you want about how they are doing it wrong, but that doesn't fix any
problems, it simply perpetuates the notion that web accessibility
advocates are inflexible and intransient in dealing with the reality of
the web today. The internet stopped being a collection of 'pages' years
ago, and pretending otherwise will get you nowhere - fast.
> As a sighted user I have no idea what this site does nor who
> those people are.
Did you ever consider, for just one second, that *because* the web is an
interactive medium that perhaps part of the 'exercise' was to click and
discover?
The page author could-have, should-have, would-have done things different
if it were Vald, but it wasn't you, it was a "design" firm, so design
esthetic was at the top of their mind. They *did* provide alt text to
those caricature images, and given the circumstances, while not optimum,
the alt text wasn't bad - when you look at that page in Lynx you have a
series of links to people's names - following those links takes you to
pages about that person. Where the site fails is the header information
and other navigational elements, as they used images instead of text, and
here omitted alt text entirely.
So if I were to approach that site owner about problems I would start
there - I wouldn't tell them that they need to rework all of those images,
the site layout, and that they did it "all wrong". Approaching any
interview/review session with that frame of mind and context ensures that
a) it's a short meeting, and b) I wouldn't be hearing back from that
client. Trust me, I learned that the hard way many, many, many years ago.
> John, if you are going to provide an example, please
> provide a best practice example that invalidates the rule I am
> proposing. Unless you are suggesting specifications and derivative
> works should teach users to write appropriate alt text for badly
> constructed Web pages.
Badly constructed is your assessment, not theirs. From a web-construction
perspective, that page almost fully validates, with 1 minor warning:
line 116 column 25 - Warning: <a> escaping malformed URI reference
I would ask them to reconsider the color contrast of the silver-gray text,
and I would certainly work to remove those "images as chunks of text" by
helping them understand that there, text vs. images would improve their
search-ability, etc. But truthfully, the alt text for the caricatures? I'm
not having any *real* problems.
And yes Vlad, we need to teach people to write good alt text for *all
manner of web pages*, not just the academic "pages" that meet your
criteria of "well constructed"...
>
> Regarding this photo site:
> http://www.zinkwazi.com/scripts/demo/phpslideshow.php?directory=photos
>
> Photos on photo sharing sites should have blank alt text. Instead,
> there should be a caption or label that is accessible to all visitors.
> Please see this:
> http://rebuildingtheweb.com/en/no-alt-text-for-photo-sharing-sites/
Yes Vlad, I've read your _opinion_ piece. I also note that many disagree
with your conclusion for a number of reasons. In the comments section with
that piece I also wrote:
"Practical outcomes trump technical purity 7 days a week
(certainly for the numerous blind and disabled users I have worked with
over the years), and *that* is what we should be striving for. Getting
overly religious about methodology stalls progress on the larger front"
So once again, telling content authors they *MUST* do something in only
one prescribed way is a fast-track ticket to nowhere. Instead we need to
help them achieve practical results, using whatever method works best for
the author as well as the end user. It's a partnership where the author
always has the upper-hand, so we need to get them to work towards our
goals, not by insisting that they do something *THIS WAY*, but by
exploring possible solutions that they can work with. As someone said to
me, "You can be right, or you can be married...".
But returning to that slideshow example and your rule, how do we provide
meaningful "textual substitute" for those images? You state:
> appropriate alternate text can only be authored by taking into
> consideration its context (content preceding and following the image).
While your point that slideshows should have richer descriptions supplied
via captions is fundamentally correct, if the design esthetic does not
allow captions for each image (as that example illustrates) what then? Alt
text might be less desirable than captions, but are still preferable than
no information at all. Taking absolute black or white stands might make
you feel righteous and on the path of good, but it rarely solves real
problems in the real world.
Besides, it wouldn't be that hard to find a page of thumbnail images that
have no room, desire or intention of providing captions to each thumbnail;
yes perhaps the full-sized image that the thumbnail represents would have
a caption, but it is simply unrealistic to expect that thumbnails will
have captions: no author is going to do that no matter how logical it may
seem to you. Now what?
>
> John wrote: "Please name one web-based 'machine' that only processes
> text, and does not process hyperlinks at the same time."
>
> Do you mean strip out the hyperlink when processing the content for a
> given purpose or when presenting that content to a user? Google does
> that. For example, here is one search result for search on longdesc:
>
> --- start ---
> 22 Aug 2010 ... How do we save longdesc ? The longdesc attribute,
> although potentially useful, was removed from the HTML5 specification,
> ...
> --- end ---
Do you take us all for idiots?
"<a done="done"
href="http://rebuildingtheweb.com/en/how-do-we-save-longdesc/" class="l"
onmousedown="return clk(this.href,',',','1',','0CBUQFjAA')"><em>How do
we save longdesc</em>?</a></h3><div class="s">Aug 22, 2010 <b>...</b>
<em>How do we save longdesc</em> ? The longdesc attribute, although
potentially useful, was removed from the HTML5 specification,<b>...</b>"
Google in *particular* processes links as part of their parsing of any
page - their entire business is built on eating links. Sure, you can copy
and paste that text and you will lose that URL reference, but the web is
not about print, it's about links, and pretending it is anything else is
ludicrous.
I tire of this discussion; you want to be right rather than solve real
problems. I wish you good luck in that.
Sorry to everyone else if my anger got the better of me. I'm done.
JF
From: Vlad Alexander (XStandard)
Date: Sun, Sep 26 2010 10:09AM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
John wrote: "Google in *particular* processes links as part of their parsing of any page..."
The purpose of the discussion was to answer the question: when a hyperlink only contains an image, should alt be written to fit surrounding content or be written as a target link label/description. I provided an example where hyperlink is removed when content is pasted into applications that only support plain text. You asked me to provide an example of a Web based machine that does that. Some parts of Google do just that. The following screen shot shows a hyperlinked sentence on the WebAIM site and then the same sentence in Google search results without a hyperlink. So, original hyperlinked content is being presented to the user as non-hyperlinked content. So I would argue that it is wrong to write alt text as a target link label/description because it can be presented to a user as non-hyperliked content.
http://rebuildingtheweb.com/misc/webaim/google-remove-hyperlink.gif
Take care,
-Vlad
From: ckrugman
Date: Tue, Sep 28 2010 9:33PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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
>
From: Vlad Alexander (XStandard)
Date: Thu, Sep 30 2010 4:15PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
I would like to share with this group that I am making the following offer to the HTML5 team in an effort to save the longdesc attribute:
http://rebuildingtheweb.com/en/offer-to-save-longdesc/
Take care,
-Vlad
From: John Foliot
Date: Thu, Sep 30 2010 6:21PM
Subject: Re: LONGDESC in HTML5?
← Previous message | Next message →
Vlad,
Let me be one of the first to say thank you for taking a positive and
proactive step here. We can only hope that HTML5 accepts the offer.
JF
>
From: Jukka K. Korpela
Date: Sat, Oct 02 2010 12:12PM
Subject: Re: LONGDESC in HTML5?
← Previous message | No next message
John Foliot wrote:
> Let me be one of the first to say thank you for taking a positive and
> proactive step here. We can only hope that HTML5 accepts the offer.
What positive step?
>> http://rebuildingtheweb.com/en/offer-to-save-longdesc/
Anyone who posts but a URL to a public discussion generally has no good
point and no good cause. If you can say in one sentence what you are
promoting or recommending, you had better not promote or recommend it.
A quick look at the page suggests that any critical comments have been
ignored and the issue has been hidden under verbosity. I wonder why someone
posts to a discussion list and then ignores any real discussion.
--
Yucca, http://www.cs.tut.fi/~jkorpela/