Quiz 4.1.1: Enforcing the use of CSS for layout
In WCAG 2.0, principle 4 states, “Content must be robust enough to work with current and future technologies.” The very first guideline in principle 4 states, “Use technologies according to specification.” It is worth a moment to go there and read the short statement and the three success criteria.
Our colleague, Becky, is a member of the WCAG 2.0 working group, and she tells me they debate how strictly to define this guideline. Specifically, she asks if they should force the use of CSS for layout, instead of tables, at the level three success criteria. Currently that level says, “Technologies are used according to specification without exception. [V]”
Q. What can we recommend for Becky?
- A Leave level three as it is today. It is broadly stated, is not muddied with “how to” details that are likely to change, is technology neutral, and is precise enough (”without exception”) to be enforceable.
- B Recommend that the minimal indicator of “according to specification” is using CSS for layout instead of tables for layout. This raises another question though. How is this stated while remaining technology neutral?
- C Recommend the principle of using technologies correctly to separate presentation from content. Something like: “Technologies are used according to specification with emphasis on separating information, functionality and structure from presentation.”
April 20th, 2005 at 8:48 am
i was going to say A, but looking back at the HTML 4 specification i realised that the specs don’t expressly prohibit the use of tables for layout, but simply give a gentle discouragement:
“Tables should not be used purely as a means to layout document content … authors should use style sheets to control layout rather than tables”. http://www.w3.org/TR/html4/struct/tables.html
now if the spec actually had a nice “MUST NOT use tables for layout”, A would be more than sufficient.
in the light of this, i’d say C (although i’d add “where possible” to that sentence, as some specs may not permit the separation of these different concerns). there may be possibly the need for a separate “techniques” document which goes into more specific details (if you’re using HTML 4, you shouldn’t use FONTs even though they’re in the spec, and only use tables for tabular data).
April 20th, 2005 at 10:19 am
I’d go with C as well. If you adhere strictly to the intended function of tables, as set out in the specifications:
“Tables should not be used purely as a means to layout document content”
Maybe a mention of semantics would tighten things up a bit. We also want people to adhere to the spirit of the specs, not just the letter and the law - something I see too much of with the current WCAG.
April 20th, 2005 at 10:31 am
mike, for me to problem comes from the fact that the HTML spec was softened up with that “purely”. does a site that uses one single layout table coupled with css and a few proper data tables use tables “purely” for layout? well no, they’re not…one for the semantics pedantics.
April 20th, 2005 at 11:04 am
C for me - it would embrace the concept without having to name TABLE specifically. With words to the effect of “use elements with the best semantics to describe the information they structure. If an element with the right semantics does not exist, author may approximate with the closest element, but authors must ensure that they do not contradict or undermine the semantics of the element they choose (eg, tables should not be used for layout; blockquote should not be used for formatting effect)
April 20th, 2005 at 11:07 am
Actually my blockquote example is about visual effects not semantic meaning - other relevant examples would be “EM should not be used for convenience where emphasis is not intended” or “headings should not be used for visual effect, if the text is not really a heading”
April 20th, 2005 at 1:19 pm
C seems like the best choice for now. Since carefully made tables can be accessible when used for layout, I don’t think they should be expressly forbidden. Also, we are still in the stage of debating exactly what consititutes tabular data; for example, is a set of thumbnails tabular data, or is it a list, or is it something else entirely?
April 20th, 2005 at 5:41 pm
Of the given options, I’d have to go with C. Stucture should be seperate from presentation, but let’s not limit everyone by giving language-specific examples.
April 21st, 2005 at 1:57 am
Was attempted to say; it doesn’t matter, since it will probably be wrong anyway pretty soon.
Instead: C, and work on a formulation that isn’t outdated before it enters final stage. Any formulation will probably have to be pretty loose if it should keep up with technology, and future technology is as unknown as most of the current technology actually is.
Stepping back just to get a broader picture:
I’m often thinking that the current technology isn’t robust enough for the content — no matter how it is provided. What it will look like in the future is anybodys guess, as technology isn’t developed along the same lines as these guidelines, and rarely ever for the end-user.
Technology itself is often not functioning according to its own specifications–if there are any specifications, so where are we?
How one should be able to get even close to reality with these guidelines is beyond me. The entire future will have to fit in here, so it is time to start on a new set of guidelines before these are released.
Oh, well. Maybe something makes sense here.
April 22nd, 2005 at 3:18 pm
I think I like “A” the best, but honestly I don’t think that “A” conveys the correct message, mainly because as far as I know, the specifications really don’t address semantics very well (I may be wrong, so please correct me). I don’t think it’s enough to just separate structure from presentation. Structure also needs to make semantic sense. Let’s face it. We’ve all seen DIV soup. You know…code which technically is separation of structure and presentation, yet is a nightmare to behold.
The single most important thing you can do to increase the accessibility of your code is valid, simple, *semantically-meaningful* markup. That needs to be addressed
April 25th, 2005 at 1:56 pm
A.
We are still using tables for layout because I have noticed that using CSS for layout currently may not be friendly to people with low-vision. I see way too many pages where text from one div overlaps text from another div, making both sets of text unreadable. Alternatively, text in one div may be hidden by text in another div.
These seems to happen with absolutely positioned items whenever a CSS-positioned page is visited with the visitor’s browser set to display text at a larger size than the page designer intended. Alternatively, this may happen if the visitor’s browser is set to a smaller window size than the designer intended (perhaps because that is the resolution the visitor needs to use to view content on a monitor of a particular size, or because they need to have multiple windows visible simultaneously on their desktop). Table layout prevents these kinds of problems; the tradeoff is that it may force horizontal scrolling on screens of certain sizes.
I am open to reading about and implementing CSS layout in place of tables if someone can point me to some model CSS layouts in which text overlap or obscuring does not occur, and which do not involve cross-browser hacks or multiple extra div’s.