On the W3C HTML Working Group’s mailing list there's been plenty of discussion about the future of the table element’s summary attribute. Should it be allowed at all in HTML 5? Should it be allowed but only “semi-valid”? Should other ways of providing information about the structure of a data table be encouraged?

One question that I have seen being asked is if people who use screen readers actually are aware that data tables may have a summary attribute and if they find the information provided in it useful.

I haven’t seen a lot of answers to that question, so I would be very interested in hearing from people who regularly use a screen reader when browsing the Web. Here are a few questions:

• What screen reader do you use?
• Do you regularly look for summary information when you encounter a data table?
• If you do look for table summaries, does the information you find help you understand the data in the table?
• Can you provide examples of data tables that you think use the summary attribute in a good way?
• Do you have any suggestions for better ways of helping screen reader users understand and navigate non-trivial data tables?

Thanks in advance for any input.

In New W3C website launched I mentioned that the W3C’s new site uses a bit of invalid CSS. A couple of readers have told me that the errors caused by vendor-specific extensions aren’t really errors, and that the CSS validator is wrong to report such property names as errors.

I wasn’t completely sure about whether or not this was true, so I did a bit of research. And, to the best of my understanding, vendor-specific extensions are invalid.

Correct grammar but still invalid

Here is the relevant part from CSS 2.1, currently in Candidate Recommendation status (emphasis mine):

A valid CSS 2.1 style sheet must be written according to the grammar of CSS 2.1. Furthermore, it must contain only at-rules, property names, and property values defined in this specification.

Vendor-specific extension (mostly) do adhere to the CSS 2.1 grammar, but since they are not defined in the CSS 2.1 specification, they are invalid. Hence the CSS validator is correct in reporting them as validation errors.

Invalid does not necessarily mean “do not use”

Invalid or not, vendor-specific extensions to CSS can be useful. And since the CSS specification requires that CSS parsers ignore declarations with an unknown property, they should also be safe to use.

The catch is that the CSS validator won’t help you catch typos or other errors in properties it knows nothing about.

An idea for the CSS validator

When using validation during QA, you have to manually filter out any errors caused by vendor-specific extensions. How much of a problem this is obviously depends on how much you use vendor-specific CSS, but there is no question that it takes longer than if you could be certain that all errors are “real” errors.

One way around this problem would be for the CSS validator to have an option to list errors caused by vendor-specific extensions in a section called “Vendor-specific”, “Experimental”, or something similar. The validator could then give you a message like this:

We found 10 errors, 10 of which are caused by vendor-specific extensions.

That way you’ll know right away if you need to take a closer look at the list of errors or not.

Just an idea.