This Week in HTML 5 – Episode 17
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:
- r2568 adds a
storageAreaattribute toStorageEventobject. [StorageEvent deficiency] - r2556 changes the processing model of the
<meta charset>attribute by requiring that it appear in the first 512 bytes of the document. For those of you playing along at home,<meta charset="...">is the new<meta http-equiv="Content-Type" content="text/html; charset=...">. Both forms are fully supported in all major browsers. [Comparing conformance requirements against real-world docs] - r2557, r2559, r2560, r2562, r2563, and r2604 add a variety of common markup errors to the list of errors that HTML validators may treat as minor. [Re: comparing conformance requirements against real-world docs]
- r2561 allows the
heightandwidthattributes on<input type="image">, a construct that is already supported by all major browsers. [Re: comparing conformance requirements against real-world docs] - r2601 adds an example of something that all browsers do anyway -- killing scripts that run too long.
- r2597 removes the notification API, which was kicked around in 2006 but never saw significant interest from either authors or browser vendors. [Notifications API removed]
- r2596 defines
window.close(),window.focus(), andwindow.blur(). Thefocus()andblur()methods have historically been used to produce "pop-up" and "pop-under" windows containing advertisements. Most modern browsers now control how and whether scripts can do this, and the HTML 5 specification goes so far as to recommend that "[u]ser agents are encouraged to ignore calls to thisblur()method entirely." - r2552 gives an example of embedding RDF metadata in XHTML. As the spec notes, this is not possible in HTML, although you could always use RDFa.
- r2595 gives an example of marking up a tag cloud.
Tune in next week for another exciting episode of "This Week in HTML 5."
RDFa cannot be validly used in HTML5, for what it’s worth. It’s still an open issue.
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.. 🙂
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 🙁
@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?
I recommend using a or @summary as needed; should read
I recommend using a caption or @summary as needed.
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.
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.
Joshue O Connor:
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 PFWG response to this issue advocates retaining the attribute (for reasons unspecified) but also says:
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. 😉
@mattur
Here’s a good place to start http://esw.w3.org/topic/HTML/SummaryForTABLE
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:
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?
[…] an interesting bit of information on how web browsers handle the src attribute of an img tag in a recent post: The problem stems from the following (arguably pointless) markup: <img src=””> A fair number […]
[…] specifically a response to the <image alt> attribute becoming optional and the omission of the headers and summary attributes in the HTML 5 table model. But the thread was quickly hijacked by a discussion of the fact that the […]