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.