The HTML 4.01 Specification includes an attribute named longdesc, intended to make images and frames more accessible to people using non-visual user agents. The HTML5 draft does not include this attribute. Some Working Group members have suggested that it be added/reinstated.
Regarding this matter, some HTML Working Members raised ISSUE-30 (longdesc). The Chairs solicited Change Proposals and Counter Proposals, and three concrete proposals have been submitted:
The question before the Working Group is which of these Change Proposals to adopt with respect to the longdesc attribute, based on which will draw the weaker objections.
Reading through the arguments, a number of proponents for various proposals did so after stating a number of concessions.
None of these are decisive. There are people who strongly support each of these proposals even after taking these facts into consideration. The fact that they were acknowledged up front was appreciated.
The weakest proposal was the one that makes longdesc conforming but with a warning. The primary rationale given for this proposal was that a few sites may be using longdesc properly. Many of the objections to both of the other proposals also apply to this one. Additionally, there was a strong argument which is unique to this proposal: if longdesc is conforming, user agents will be required to support it; if there is a validator warning, users will be discouraged from using it. This combination is the worst of all possibilities. Eliminating this proposal early made the process of coming to a resolution simpler.
The existence of implementations was found to be a weak argument for inclusion, the quantify of bad data was found to be weak argument against inclusion. External references (standards, laws, etc) was also found to be a weak argument for inclusion.
The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don't see this feature to be compelling, and the lack of user demand has been noticed by implementors.
Therefore, the HTML Working Group hereby adopts the Change Proposal to not include the longdesc attribute in the language. Of the three Change Proposals before us, this one has drawn the weaker objections.
As this issue predated the decision policy, there is no associated bug report to be closed as WGDecision.
Since the prevailing Change Proposal does not call for a spec change, no further actions are required.
If anyone feels they have not received due process, or that their concerns have not being duly considered in the course of reaching this decision, they may make their concerns known to the Team Contact (Mike Smith) who will notify the Director.
If anyone strongly disagrees with the content of the decision and would like to raise a Formal Objection, they may do so at this time. Formal Objections are reviewed by the Director in consultation with the Team. Ordinarily, Formal Objections are only reviewed as part of a transition request. In the case of this issue, the Chairs have agreed to forward Formal Objections right away for expedited processing.
Anyone who would like to take either of these steps should first read the Review of Arguments Presented, below.
This issue can be reopened if new information come up. Examples of possible relevant new information include:
It was stated that the longdesc feature was implemented multiple times successfully. Cited were Opera, Firefox (which apparently subsequently removed this feature), Dreamweaver, and XStandard. Newer versions of IE may produce a tooltip based on this information under certain circumstances. No criteria was provided for the adjective "successfully".
A counter argument was given that implementation is a necessary but not sufficient justification for inclusion. This was found to be a strong counter-argument.
Overall, it was found that this while this attribute is implemented, it is not implemented widely. This necessarily makes this objection a weak objection.
It was asserted that bad data had a low impact on implementations, and further that users benefit from good usage. Neither assertion was clearly established based on the evidence provided.
It was argued that this attribute was poorly named, and that as invisible metadata it would have a tendency to rot. These assertions may very well be true, and could explain the bad data that has been seen. As stated previously, the existence of bad data is not in question.
It was further asserted that this would result in a lower quality AT experience as users would quickly learn to ignore longdesc based on bad usage. This evidence that was used to support this was highly anecdotal or non-scientific. Additionally, no evidence was provided that it would be difficult or impossible for user agents to identify and make good use of correct usage.
Overall, it was found that all incorrect usage objections were weak.
It was stated that without this attribute, there is no current way to reference a longer description of an images without including the content in the main flow of a page. It was further stated that user agents could very well open this content in a new window. While the former is uncontested, no evidence was provided that this is a necessary or even desirable characteristic; in fact arguments were presented by others to the contrary. As to the latter, this was expressed in a hypothetical manner, and therefore was not given much weight.
A number of use cases for semantically rich, structured descriptions of images were provided, however those use cases are abstract and don't directly and specifically require the support of a longdesc attribute. Many objected to inclusion of features in the language that have proven to be problematic and don't support any known use cases. This objection was found to be strong.
It was argued that a native feature would be preferred over ARIA bridging. This argument would apply if the feature had known use cases. Similarly, it was argued that the lack of this feature would represent backsliding. Again, the lack of identified use cases makes this moot.
It was argued that having less (and simpler) options is better than more (and complex) options. Once again, there is no need to evaluate this argument without the clear linkage between an identified use case and this specific feature.
Overall, the lack of identified use cases was found to be a strong objection.
It was noted that longdesc appears in WAI Guidelines, Section 508 Standards, and Dutch Law. An anecdotal first person statement was made by an educator that "I teach web development, and I always teach longdesc". These are valid, point in time, arguments for considering adding/reinstating longdesc. However they are only point in time arguments: after all, guidelines, standards, law, and curriculum can and do evolve.
A counter argument of "no stated reason that this feature will actually be used more in the coming 10 years than it has in the past 10 years" was given. This observation significantly reduces the weight of the argument of references by the various guidelines, standards, etc. Put another way, if longdesc were an important component of these efforts, you would expect that with this length of time there would be ample evidence to point to of usage, correct or otherwise.
Lacking such evidence, this was considered to be a weak argument.