The WHATWG Blog

Please leave your sense of logic at the door, thanks!

This Week in HTML 5 – Episode 17

by Mark Pilgrim, Google in Weekly Review

Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.

The big news this week is a major revamp of table headers, following up from the last major edits last March. Ian summarizes the most recent round of changes:

  • Header cells can now themselves have headers.
  • I have reversed the way the algorithm is presented, such that it starts from a cell and reports the headers rather than generating the list of headers for each cell on a header-by-header basis.
  • If headers="" points to a <td> element, the association is set up, but I have left this non-conforming to help authors catch mistakes.
  • Header cells that are automatically associating do not stop associating when they hit equivalent cells unless they have also hit a <td> first.
  • The "col" and "row" scope values now act like the implied auto value except that they force the direction.
  • Empty header cells don't get automatically associated.
  • I have removed the wide header cell heuristic.
  • I have made headers="" use the same ID discovery mechanism as getElementById(), to avoid implementations having to support multiple such mechanisms.
  • Finally, I have made the spec define if a header is a column header or a row header in the case where scope="" is omitted.
  • I haven't added summary="" on table; nothing particularly new has been raised on the topic since the last times I looked at this.

Accessibility advocates are disappointed by the continued non-inclusion of the summary attribute. Their reasoning is that "the summary attribute is a very, very practical and useful attribute," despite their own user testing that shows otherwise. As Ian put it, "I am hesitant to include a feature like summary="" when all evidence seems to point to it being widely misused by authors and ignored by the users it intends to help." As with all issues, this is not the final word on the matter, but it's where we stand today.

In other news, r2566 addresses a very subtle issue with fetching images. The problem stems from the following (arguably pointless) markup: <img src=""> A fair number of web pages actually try to declare an image with an empty src attribute. According to the HTTP and URL specifications, this markup means that there is an image at the same address as the HTML document -- a theoretically possible but highly unlikely scenario. Internet Explorer apparently catches this mistake and just silently drops the image. Other browsers do not; they will actually try to fetch the image, which results in a "duplicate" request for the page (once to successfully retrieve the page, and again to unsuccessfully retrieve the image).

Boris Zbarsky, a leading Mozilla developer, states

We (Gecko) have had 28 independent bug reports filed (with people bothering to create an account in the bug database, etc) about the behavior difference from IE here. That's a much larger number of bug reports than we usually get about a given issue. I can't tell you why this pattern is so common (e.g. whether some authoring frameworks produce it in some cases), but it seems that a number of web developers not only produce markup like this but notice the requests in their HTTP logs and file bugs about it.

r2566 addresses the issue by special-casing <img src> to allow browsers to ignore an image if its fetch request would result in fetching exactly the same URL as its HTML document:

When an img is created with a src attribute, and whenever the src attribute is set subsequently, the user agent must fetch the resource specifed by the src attribute's value, unless the user agent cannot support images, or its support for images has been disabled, or the user agent only fetches elements on demand, or the element's src attribute has a value that is an ignored self-reference.

The src attribute's value is an ignored self-reference if its value is the empty string, and the base URI of the element is the same as the document's address.

Other interesting tidbits this week:

Tune in next week for another exciting episode of "This Week in HTML 5."

12 Responses to “This Week in HTML 5 – Episode 17”

  1. Not all browsers kill long-running scripts – Opera doesn’t, because we always keep the UI fairly responsive anyway so we don’t need a “slow script warning”. One of these minor but very significant features that set us apart.. 🙂

  2. but it seems that a number of web developers not only produce markup like this but notice the requests in their HTTP logs and file bugs about it.

    The html validator didn’t notify me of an img tag with no src value and it happened when I was mostly focusing on server side code to manage content so the validity of the html and image sources weren’t my primary concern.

    I only noticed because the loading that page should result in 1 new record in the database but because I had 4 empty img tags there were 5 new records 🙁 Took me an hour to realize the problem was the browser and not my code 🙁

  3. @Mark:
    FWIW My user testing video does /not/ prove that @summary is not useful. In it one person stated that a long description is not always necessary for a simple table, and that they didn’t find it useful. That person is also a power user, technical, and knows how to interrogate complex data tables using a series of complex keystrokes. So in a sense he doesn’t really need the attribute and can make statements like that. He is not representative of the majority of users who would find the attribute useful.

    With every accessibility audit I do that includes complex data tables I recommend using a or @summary as needed. What developer worth their salt would not? To me is seems that people who wish to remove @summary either do not know users with disabilities, or feel that their theoretical understanding of a specification will suddenly make them a sufficient authority on accessibility, ” ‘cos its mentioned in the spec”. This is just not the case. There is a major disconnect between how a spec is conceived and how it is implemented in the real world. It’s a source of amazement to me that I have to vocalize this fact ad nauseam.

    Would you prefer people with disabilities having to upgrade their expensive AT to support the blue sky ideals of a new specification, to do what can already be done by an existing attribute that is supported? I would hope not. Removing attributes like @summary is the thin end of the wedge towards this kind of thing. The vendors won’t complain as they wish to sell products but many people with disabilities are are on low incomes if they are employed at all. This fact seems to escape the attention of the ivory tower.

    As an aside, I included the above mentioned comment in my footage in the spirit of openness and transparency. I am concerned about the integrity of my research and the advice I give. May be I should reconsider this stance considering the kind of loaded comments that appear here, as it doesn’t seem this spirit is reciprocated?

  4. Would you prefer people with disabilities having to upgrade their expensive AT to support the blue sky ideals of a new specification, to do what can already be done by an existing attribute that is supported?

    This is a false dichotomy; it assumes that not including the summary attribute in HTML 5 will cause web pages to become less accessible unless a newer UA is used. Yet the heart of the reason summary has not been added to HTML 5 is that no-one has provided convincing evidence that it is having any effect whatsoever on accessibility of HTML 4 documents. Indeed the various studies that have been done (and not just your video) suggests that it cannot be having very much impact at all since it is almost never used and, even when present, rarely very helpful. If the summary attribute is as essential as you claim then surely it is worthwhile to demonstrate (rather than merely argue) its utility. Yet so far no one has done so.

    It is also worth noting that the sad status-quo of overpriced AT that precludes many users from access to the latest technology will likely change with the coming of age of various free (both Open Source and free-as-in-bundled with the OS) AT solutions. If those products can offer the majority of the functionality of their expensive rivals then the market leaders will be forced to reduce their prices or, at least, people will have the option to use the high-quality free alternative. It seems like inverting time in improving these products will have more of a positive impact on the users of AT than spending the same hours in unproductive debate about a little-used HTML attribute.

  5. The atttribute was little used as developers were often just not aware of its value. One of the reasons I got involved in Web Standards in the first place is to advocate for quality web development. In my mind an attribute like @summary is a part of the toolkit which developers are just not aware of, for whatever reason, but did have a positive impact, in particular for people with disabilities. I have direct experience of working with people with disabilities hence my ad nauseam advice to retain the attribute. Obviously my approach to this issue has failed and no doubt my methodology can be improved. Aun aprendo.

    What I have learned is how little the advice of those who actually do know something about accessibility has been heeded. Also the requirements of the WG for “evidence” and “proof” are movable goal posts. You may understand this chameleon better than I but it seems to me if you don’t know what you are looking for any proof will do.

    At this stage it seems no evidence or argument would be sufficient to warrant its retention. Currently, @summary seems destined to drown under the weight of its relative statistical insignificance rather than be retained due to its inherent merits which it seems that no one except a handful seem to be aware of, or for whatever reason, choose to ignore.

  6. Joshue O Connor:

    At this stage it seems no evidence or argument would be sufficient to warrant its retention.

    It would help if you actually posted your arguments, in addition to citing your experience and (understandable) frustration. I don’t think the case for keeping the table summary attribute is as clear cut as you suggest.

    As the WCAG1 Errata Introduction points out:

    …the summary attribute […] is hidden from anyone who can see, including some other persons with disabilities [who would also benefit from this information].

    The PFWG response to this issue advocates retaining the attribute (for reasons unspecified) but also says:

    3. element content providing this info, *if linked by markup to the table* offers growth to even better practice

    Using visible text for table summary information appears to be a better, more accessible solution – even without an explicit markup link.

    Sighted users when reading a complex data table would look at text before or after the table for an explanation. AT users don’t require special markup to do the same thing.

    Again, it would help if the arguments for these solutions were made somewhere, so we could all understand the issues involved.

    “Because Person X/Group Y says so” is never going to be a convincing argument for techies. The response is always going to be: why? It’s the way we’re wired. We can’t help it. 😉

  7. Thanks Joshue.

    The wiki page you refer to makes the case for summarising data tables. It doesn’t make the case for a table summary method that is invisible to most users but visible to AT users. The “In the Wild” examples don’t help… 😉

    Are there any situations where moving the summary attribute’s (useful) content into visible page text would not lead to improved accessibility?

    There’s a good example on the WebAim website: Provide Summaries Using the summary Attribute:

    A complex table of weather data might have a summary that says:

    “A warming trend has been observed in Cache Valley, with temperatures about 5 degrees above historical averages over the last two months, with the highest temperature difference being 25 degrees above average.”

    Clearly, other users would also benefit from this summary, not just AT users.

    Are there situations where the table summary is not beneficial to any other users and/or the summary cannot be displayed as visible page text?