Recovered from the Wayback Machine.
In preparation for HTML5 Last Call, the HTML WG (Working Group) co-chairs have been rolling out several decisions—among them ones related to the
img longdesc and
table summary attributes.
The HTML decision on longdesc was based on the following observation:
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.
I agree with the decision of re-opening the issue, but feel that the original decision against londesc to have been made in error. The co-chairs stated in the earlier decision that the use cases stated in the original change proposal to keep longdesc were abstract, rather than actual use cases. However, the existence, or not, of use cases has not been a noticeable decision criteria for most of HTML5. Why then this seemingly inconsistent demand for one attribute, when the same demand has not been made of other attributes?
As an example, where is the non-abstract use case for a hidden attribute? There’s was little or no interest in this attribute at the time it was created or renamed from “irrelevant” to “hidden”. The only time the attribute seems to have generated interest is when I filed a change proposal to remove it. The grand implementation plan for it is to set it’s default styling as “display: none”, and automatically add an ARIA value of aria-hidden—both of which can be done now, easily, and without having to use a special purpose attribute.
However, the WG co-chair decision on hidden was that implementors and authors were interested in the attribute. So, hidden stayed.
Yet authors also expressed an interest in keeping longdesc. We know from the discussions before the longdesc poll that people were interested in, even passionate about longdesc. Additionally, if we compare actual implementations between the two, there is broader implementation support for longdesc than hidden.
More importantly, unlike the hidden attribute, which duplicates simple to use and existing technology, there is no replacement for longdesc. If we consider that longdesc’s value is to hold a URI that points to a complex description of the image typically maintained in a separate web page, and to do so without providing a visual indicator in the page, no one has come up with an alternative that provides the same functionality that longdesc provides.
If the concept of deprecation was still supported in HTML5, the lack of alternative would have been obviously evident. Yet, elements and attributes can be moved directly from actively supported to actively discouraged, without regard for existing implementations. As Laura has so ably demonstrated—longdesc has seen use, has been implemented, and there is at least some support for the attribute.
The same can be said for
table summary and the decision to make this attribute obsolete. Again, this attribute has a specific use: to provide a textual description of the visual infrastructure of an HTML table for complex tables. Like
img longdesc, many HTML tables won’t need a summary attribute. When one is needed, though, there is no alternative to provide this information in the manner that summary provided—a text description that is primarily focused at those using AT devices, such as a screenreader.
Putting the information into the text is redundant, and will be irritating for most people reading the page. Frankly, web page authors just won’t do it.
Providing it in the caption is an inappropriate use of the
caption element. We’re told to break the complex data table into simpler tables, but it’s not up to us to say what is or is not an acceptable table structure—not just to provide justification for making obsolete an existing attribute.
How about actual uses of summary? One reason for pulling both
table summary and
img longdesc is that both have been used incorrectly in the past. Well, without raiding Google’s data store, I’m reasonably certain we’d find the same thing can be said about most HTML 4 elements. Without having to resort to prescience, I’m also fairly certain the same will eventually be said of
Another reason for pulling both longdesc and summary is that hidden metadata is bad. Hidden metadata…balderdash. There is no “hidden” metadata—all the data in the web page is “visible” to some audience. And no, the data doesn’t all have to be available to all audiences. One of the arguments against
table summary is that supposedly the information would be useful for others, such as those with cognitive disabilities. However, providing an exact textual description of the table seems more like additional noise for those who have cognition problems than a helpful device. I’m not an accessibility expert, but from a commonsense perspective, I have a difficult time understanding how something that is supposed to help the blind is also going to help those with completely different challenges. Is accessibility really one-size-fits-all?
The other “hidden metadata” argument is that if people copy and paste the
table, or the
img, the resource will become separated from the accessibility aid. This has been used as a primary argument against longdesc because this attribute can include a relative link, which will break if used in a different domain. Well, I don’t know who copies HTML tables, but if they do, they’ll do so in source, and copy and paste the whole thing. And copying an image doesn’t mean view-source and then copying the img element—it means right clicking on the actual graphic, and then saving it to our computers for use elsewhere.
So, we have one attribute, hidden, that’s easily re-produced with existing technologies, and with little or no use case support other than a group of people saying they want it when it’s existence was threatened, and we have two others—
img longdesc and
table summary—that can’t be replaced with existing technologies and have real world uses, but we keep the former and get rid of the latter.
I hope I can be forgiven for saying that the decisions seem…inconsistent.