At Cre8asite Forums this week, a lengthy discussion on the ultimate value of pure CSS (Cascading Style Sheets) based layout over the use of tables has been taking place. Sometimes, living in the sheltered world of accessible and standards-based design, I can lose touch with the fact that many people out there simply don’t accept some of the same guidelines I work with every day — and that this does not, in any way, mean that they haven’t given the subject a fair shot. Very good arguments have been made to defend each side.

On the whole, I think this discussion is an old, worn-out subject: those who won’t use tables generally don’t use them out of principle, and those who do use them out of pragmatism and a justified awareness that principles don’t build websites. I want to review the question once more, however, ignoring the entire question of principle.

Read more: Why not tables? Is CSS really better?

I’ve been thinking about the language of personal names recently. Commonly, personal names don’t follow the pronunciation rules of their locality. My name is “Joe.” That’s an easy one. But you can’t be sure. My partner is named “Janna” — pronounced “Yahn-uh.” In this country, it’s the very rare exception when a stranger pronounces her name correctly.

It’s embarrassing to mispronounce somebody’s name. Outside of a personal introduction, however, it can be very difficult to know how to pronounce personal names because of these numerous deviations from the rules of pronunciation. (Which, in English, are already pretty nasty.)

But using language to markup a personal name may be somewhat deceptive or inaccurate.

Read more: Personal Names and Language Choice

Robert Nyman has questions he’d love to have answered about SEO. I’m not the person to answer these questions, certainly, but I can certainly provide commentary.

In particular, it’s nice to see people from the web standards community discussing search optimization. There’s no question that creating a website which applies web standards and the principles of accessibility also creates a nice landing spot for search engines. When you build accessibly, you remove barriers to access for search engines as well as users. Although accessibility and web standards are certainly not necessary for search engine success, they can be an excellent way to kickstart your campaign. New websites in particular are likely to benefit from the crawlability and easy navigation aided by conscientious construction.

Read more: Standards, Accessibility, and Search Engine Optimization

The <br /> tag seems to get short shrift a lot. Perhaps because it contains no content and appears to have no meaning within a document. You can’t communicate any of the information that a line-break contains structurally because it seems to be a purely presentational element.

Robert Nyman boils the issue down to a number of different perspectives on line breaks: “no”, “yes”, “I don’t know”, and “who cares?” (Perspectives have been paraphrased. A lot.)

Read more: Is a br tag semantic?

This is a question which came up once upon a time at Cre8asite Forums, and it intrigued me. An interview, next to a standard article format, is possibly the most common type of written document on the web. Interviews pretty much always follow a very straightforward sequence: Question and Answer. An interview may have one interviewer with one interviewee, or may have several of each. In either case, the tag should be able to support some form of citation to specify the currently speaking party.

There is no perfect semantic solution for formatting an interview, I’m afraid.

Some of the most commonly used choices might include heading tags and paragraphs, definition lists, or simple sequences of paragraphs. None of these really support the characteristics necessary for an ideal interview.

So we need to fake it; or create something new. I don’t really want to get into what’s required to add custom elements to a custom DTD. Sure, you can create your own valid XHTML document type declaration and create an interview element – but I don’t think that’s really the best solution. What value does a beautiful semantic element have if no user agent will identify it?

Perhaps a microformat would be a good idea: and, in fact, it has been discussed, although the idea hasn’t gotten very far. The chief direction it’s tended to take has been using implementation through a definition list. Lacking anything better, that’s probably the best choice. I’m not up to writing a microformat today, I’m afraid, but I’m going to force you all to suffer through my contemplation of how an interview might best be organized anyhow.

A definition list consists of three parts: the list block <dl>, a "term", <dt>, which is a block of text which is definitely associated with <dd>, it’s "definition". The main reason that this format is flawed for an interview or for dialogue, in my mind, is in the lack of any semantic means to identify the speaker.

An interview might be written like this:


<dl>
<dt>What do you think about questions?</dt>
<dd>Well, I'm not really interested.</dd>
<dd>Neither am I, really.</dd>
<dd>That's interesting!</dd>
</dl>


You can see that it’s very difficult to say who’s speaking. If you were to assume that any given interview only involved two people and that they exchanged a single question for one or more answers, the definition list works very effectively. However, when you consider the possibility of multiple individuals being interviewed and responses from the interviewer which are not questions, things may get a little complicated…

It’s a simple matter to label the speakers in plain HTML text, to make it clear who is speaking, of course. That’s really not the point, however – when I’m talking about semantic formatting, I’m specifically trying to get at the most machine-readable manner of identifying a format. XML accomplishes this quite easily:


<interview>
<question num="1">
<interviewer type="question" name="Joe Dolson">What do you think about questions?</interviewer>
<responder type="response" name="Evil Twin">Well, I'm not really interested.</responder>
<responder type="response" name="Split Personality">Neither am I, really.</responder>
<interviewer type="response" name="Joe Dolson">That's interesting!</interviewer>
</question>
</interview>


Here, specification is provided about what sequence the questions are coming in, who is speaking, whether they are asking a question or responding to one, and could easily provide even more information.

Sadly, HTML does not provide the ability to define your own attributes quite so easily! If you were to write your interviews out in XML and then use XSLT to transform the text into HTML on the fly you could leave the information accessible to any device with the ability to process XML while providing a clean layout for other agents – at least, for agents which support XSLT.

What it comes right down to is that, in my opinion, the lack of any format which can fully support the semantic needs of interview or dialogue means that you shouldn’t spend too much effort worrying about how to write them out. I certainly wouldn’t recommend just using paragraphs: some manner of differentiating questions and answers is still pretty important, but the level of detail in the HTML and XHTML specifications don’t provide anything which is really suitable.

Normal use of headings and paragraphs may well be sufficient – a definition list could be better for some interviews, but for others could simply be less effective.

Loren Baker recently published an article by Mikhail Tuknov entitled Benefits of CSS in Search Engine Optimization. It’s a basic article describing the potential benefits of cascading style sheets in regards to SEO, maintenance, etc. General purpose CSS advocacy. In general, if you aren’t convinced that CSS is worth using, it’s probably worth reading – however, it does emphasize one fallacy which is, personally, a pet peeve.

CSS makes your website more accessible. […] By separating style from markup, webmasters can simplify and clean up the HTML in their documents, making the documents more accessible.

Mikhail Tuknov

No, it doesn’t. Cascading style sheets are a design methodology: they mean that you are separating the design of your site from the structure of your site. This can unquestionably have benefits for website accessibility, but it most certainly does not mean that your site is now accessible. Like any method, CSS can be used equally to create a high quality, standards-based website which is very accesible or a piss-poor website which is unusuable by anybody with less than perfect vision and an innate understanding of Urdu.

The separation of style from markup alone is not sufficient to be able to claim any level of accessibility at all. Use of CSS does not entitle you to claiming any form of accessibility. Semantic markup does not grant accessibility. Website accessibility is a combination of factors including semantic and valid HTML or XHTML, valid CSS, and conscientious attention to code order, positioning methods, keyboard accessibility, correct application of labels, sensitivity to color contrasts and uses and authorship of texts which do not require sight, color vision or any specialized knowledge to understand. This is no full spectrum description of accessibility – merely a light brush along the surface. To make the claim that “CSS makes your website more accessible” is such a gross simplification of the reality that it rather gets under my skin.

I feel like it’s a common misperception that learning how to program valid websites and use CSS are the main needs in learning to create accessible designs. Actually, the most important thing is to learn how people with disabilities or alternate access devices actually use the internet. Learning about disability is the most important first step, so you can comprehend the difficulties that need to be surmounted. Valid code and CSS are a path in that direction, because they make translation by multiple user agents easier – they are not, however, inherently accessible.

Part of building an accessible website is making meaningful choices in the code you use to markup your content. In some cases, this is a very easy decision: <p> descrbes a paragraph, <blockquote> describes a blocked quote, and <acronym> describes an acronym. No problems.

But some issues are more complex: take the calendar. What is the logical structure of a calendar? Is it tabular data? Is it an ordered list? Is it a definition list? All of these are completely reasonable and logically justifiable structures for a calendar: how do you pick?

Tabular Calendar Structure

In a table structure, the columns represent days of the week, rows represent the week number of the month or year. In practical use, weeks of the year are rarely applied. The Vienna (Austria) transit system uses them: buying a weekly pass gives you transit access for that specific week of the year, but I’ve rarely seen them in other applications. Weeks of the month, however, are in frequent use: Thanksgiving is always the fourth Thursday in November, Election Day is the second Tuesday in November.

So, the tabular structure is reasonably well justified. Colloquial language does actually use those data references for the information, so, if appropriately marked up, this seems reasonable. It’s not perfect, however: the layout inevitably means that either the table will inevitably contain data for a previous month, or will contain empty cells. Not the end of the world; but imperfect.

Ordered List Structure

Time is, for most people, a pretty linear experience. As such, dates can very reasonably be structured sequentially. Again, only really usable for single month length calendars, as the numbering must repeat otherwise, but reasonable. This is certainly a data structure in normal use: the 22nd day of October, etc. The list itself could be labeled with the month, each day would be a list item. In addition, the days of the month would be automatically numerically labeled appropriately. Additional data for the day could conceivably be contained in a nested list.

This layout is a less common look for print calendars; so users are likely to be less familiar with it. However, it’s certainly a reasonable approach.

Definition List Structure

The days of a month can be described as the definition of that month: February is a month containing these 28 days. Each day, furthermore, can be defined by the events of the day. From a structural perspective, this is significantly similar to the ordered list approach. Definition lists do have one advantage, however: each list item has an independent definition. Although not necessary for a basic calendar, these could be useful for an events calendar.

I tend to feel that a definition list stretches the semantic association a bit too far: although a <dl> can be applied for a calendar, and with some justification, it seems to stretch a bit beyond the fundamental meaning of a list of definitions.

Conclusion?

Ultimately, there is no one structure which is perfectly suited for a calendar. Dates are referenced and used in a significant number of ways: the visual layout should generally be that of a table, because this is what most users are familiar with. Usability would certainly suggest that familiarity should carry some weight.

My own tendency is to use tables. That is the visual layout I want; and I see a very reasonable justification for the semantics. I don’t believe there are any major hurdles to accessibility, as long as the table has been appropriately designed.