Describing a Semantic Calendar

October 16, 2006

Topics: Accessibility, Semantics, Usability, Web standards.

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.

3 Comments to “Describing a Semantic Calendar”

  1. Thanks for the feedback.

  2. A definition list is appropriate for any data which is fundamentally a “call and response”/”question and answer” information set. As such, what you’re describing seems like it would be perfectly appropriate.

    I have to say that I think a table would be perfectly acceptable, as well, of course. Semantics aren’t really a fixed feature: for complex data sets, there are commonly multiple appropriate solutions. I could go either way on this particular question!

    It’s important not to worry too much about whether you’ve chosen the “right” answer in semantics. Basically, you can always choose to use the wrong element — but choosing the right one is much more difficult.

    If you can explain your reasoning for a specific element choice from a semantic perspective, you’re fine.

  3. We are putting together a list of features in a specific area of our site in which each feature has its own html page and all of the features together, however, are presented on an “overview” page.

    The immediate approach was to put this together as a table in which the headers were “Feature” & “Benefit”, but came to the conclusion that this is not tabular data and that, being a list of features & summarised benefit, it would be more semantically correct to present them as a list.

    We have never used definition lists before and are not sure whether this would be the right place to use them.

    So we would have, as an example, dt of ‘speed’ with a dl of ‘so you can get from a to b in time for dinner’. Would this be correct and, if so, what about what we would have used as table headers (i.e. feature & benefit) – do they also fall in this category?