Diversity Specs

W3C HTML WG decisions and the ARIA meltdown

Recovered from the Wayback Machine.

One last decision I want to touch on, for now, was the decision related to Issue 129 on ARIA Mapping. In the decision, the co-chairs sided with the change proposal that added new role mappings for several elements. An uncomplicated change proposal that should require only some small edits to the ARIA mapping table.

However, things are never as simple as they seem.

First, the change tracking shows the addition of interesting new editorial comments related to this change:

These are issues that are known to the editor but cannot be
currently fixed because they were introduced by Sam Ruby
acting as chairman of the W3C HTML Working Group as part of
the HTML Working Group Decision Process. In theory we could
fork the WHATWG copy of the spec, but doing so would introduce
normative differences between the W3C and WHATWG specs and
these issues are not worth the hassle that this would cause.
We’ll probably be able to fix them some day, but for now we
are living with them.

In addition, evidently the changes made to the HTML5 spec didn’t agree with the change proposal, as noted by Steve Faulkner. To make a long, sad story short: a request was made to revert the changes and the editor must bring whatever changes he makes to meet the decisoin to the working group, first, before applying to the document.

I’m, personally, less bothered by the editorial errors than I am the discussion about forking. In many ways, this only demonstrates why the license discussion, which also seems to be never-ending, is essential: forking a specification is not the same as forking software. And there’s too much of a tendency among some folks in the WHATWG to want to fork, first, and then work through the issues.

I’m also concerned that these issues will continue to arise, time and again, because folks at the W3C are dancing around the edges of the problem, rather than confronting the problem directly. However, if the W3C does respond assertively, there is a very real possibility of one or more browser companies taking their marbles and quitting the game.

It’s a damnable situation.


The W3C HTML WG decision on RDFa prefixes

Recovered from the Wayback Machine.

One HTML WG decision I agree with is the one associated with Issue 120 on RDFa prefixes.

Considering that RDFa support in XHTML/HTML to this point has made use of prefixes, I don’t understand why we even contemplated not supporting prefixes just because RDFa is being ported to HTML5. Frankly, it’s not the HTML5 WG’s design decision to make—RDFa in HTML5 is a port, the design for RDFa resides with another group.

As for RDFa prefixes being confusing, one of the most fundamental design patterns, in computer tech and elsewhere, is the concept of variable/value pairs, with a shorter, easy to type and remember variable or abbreviation used in place of a longer, more complex value.

Then there’s the fact that RDFa has significant adoption, and dropping support for prefixes will break the web. I’ve heard that this is an important criteria for other HTML5 design decisions. If nothing else, consistency demands we support prefixes.

I could go on, but the proposal to keep prefixes does a commendable job and I don’t need to repeat its arguments.


W3C HTML WG Decisions: hidden, longdesc, table summary, and the myth of hidden metadata

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.

The issue was later re-opened, primarily because of the collection of formal use cases, aggregated through the efforts of WG member, Laura Carlson.

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 hgroupfigureasidesection, and article.

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.