Many web sites use calendars to provide a timeline of events as a narrow visual grid, often in a side column. While this format is not well suited for blind and visually impaired users, the right structural mark-up can make such calendars more accessible.
Nearly always, web calendars present one month at a time in a seven-column HTML table.. The styling varies, but the basic pattern is well established. The days of the week run as column headers across at the top. Usually, dates that carry events are rendered as links to a corresponding event description (or event list, in case of several events).
The conventional nature of the calendar grid means that sighted users can quickly pull together the dispersed information elements. The eye follows the row up to the day, and tool tips can indicate the event in the title attribute of the date's link. In contrast, screen reader users may encounter the calendar as a linear sequence unless they chose the table mode. That is why the relation between date, day, and associated event has to be made explicit through the use of proper table mark-up, especially the correct use of table headers.
The grid format and usually limited width of the calendar impose constraints on the column headers containing the days. Since the full day names would be too long, one-, two-, or three-letter abbreviations are used instead, such as Mon, Tue, Wed, Thu, Fri, Sat, Sun. Even the minimal and ambiguous rendering M, T, W, T, F, S, S can be found.
The calendar is there for a purpose beyond indicating the date of today: it aims to give access to events. The narrow matrix does not easily accommodate event information beyond just indicating whether a day has events associated to it at all (by applying a different style and a link). Truth be told, other forms (text with structured headings, a tabular format, or a list) seem much better suited to provide a quick overview of events over time.
Get rid of the calendar, then? Possibly. But let's assume the client or developer has fallen in love with it and wants it as a cute visual element on the page.
Since the link text in the cell is just a number, some means have to be found to present the event information outside the grid.
Developers who want to provide event information without leaving the page can resort to dynamic elements to show event detail when the corresponding date receives focus. A look at two recent accessible calendar implementations using dynamic elements will show two different ways to implement this concept.
The first example is the calendar on the website www.einfach-teilhaben.de, an information portal for people with disabilities (see figure 1). In view of the audience, it was very important to make this calendar as accessible as possible. The design was tested with users with different disabilities and modified in response to problems identified. (Aperto, the company responsible for the front-end design, has reported of the user testing: einfach-teilhaben.de im Usability-Test mit Menschen mit Behinderungen).
Figure 1: Calendar on the information portal "einfach teilhaben" (www.einfach-teilhaben.de)
Just a note on what happens 'behind the scenes': When the page loads, the calendar is rendered dynamically through an AJAX request and marked up with WAI ARIA attributes (we are not going to discuss the details of using WAI ARIA in this article). Navigating to adjacent months updates the calendar on the fly, without a page reload.
Using the keyboard to tab through the calendar, the focus runs through the dates with links (events). The focus is indicated through underlining. Pressing 'Enter' on a focused date opens up a small popup box with the headline "Termine am 7. Mai" that lists the events of that date. If a date has more than three events, the list is truncated and a third link leads to an overview of events in a data table on a separate page. After tabbing through the links in the pop-up box, the focus moves on to the next date in the calendar, and the box closes automatically.
It is worth noting that the mouse focus deviates from the keyboard focus. Moving the mouse over a date with events immediately displays the popup box while keyboard tabbing just moves the focus to the next date.
When I asked Aperto whether this had been done on purpose, I was told that user testing had indicated that presenting the pop-up-box immediately on receipt of keyboard focus was considered too distracting. During non-linear mouse access, this distraction is much less obvious because there is no need to move sequentially through the links as in keyboard tabbing, tipping the scale towards the immediate display of the box.
h3 headline "Veranstaltungen im April 2010", all days carrying events (and just those) are rendered as
h4 headlines followed by the list of events for that day. This offers a structured good overview for people using their own or no stylesheet and facilitates headline navigation by screen reader users.
A nice touch is the use of invisible text to provide more descriptive information to screen reader users (and users using their own or no style sheets). The visible headline above the calendar, "Mai 2010", is expanded to "Termine / Veranstaltungen im Mai 2010", and the bare numbers in the table grid are augmented to read out, for example, "7. Mai" (or "Termine am 7. Mai" if a date has events associated to it). When pressing 'enter' with the focus on such a link, the screenreader will again read "Termine am 7. Mai", the headline of the box, and after that, the linked event entries for that day. This doubling up is fine since it works as a confirmation of a user-initiated action. It is only slightly distracting for sighted users viewing the calendar with CSS disabled (see figure 2, "Termine an 13. April").
Figure 2: View of the calendar with CSS disabled
The calendar without CSS is fully functional but its visual presentation is poor. It would be improved if the grid was made visible by setting the table's border attribute to 1 (possibly this was avoided to prevent undesirable visual renderings in older browsers).
The calendar on 'einfach teilhaben' can serve as best-practice example for all who want this format. It is well-structured, events are integrated with dates, and accessibility is equally good for both mouse and keyboard users.
wuk.at is the website of the Werkstätten- und Kulturhaus in Vienna, a big cultural event location. The site was recently re-launched with a focus on accessibility (see figure 3). With events on each day (sometimes more than thirty), the calendar features prominently on the WUK website. It is constantly available, not just on the start page, but also on all other pages carrying event overviews or descriptions.
Figure 3: Start page of Werkstätten- und Kulturhaus Wien (www.wuk.at)
Figure 4: A mouse-over on a date displays a dynamic table with events on that date
The WUK calendar has a dynamic feature designed specifically for mouse users. When the mouse is moved over a calendar date, a pop-up table carrying event information for the respective day is displayed immediately to the left of the calendar, temporarily hiding the page content.
In contrast, when tabbing through the calendar with the keyboard, the event tables are not shown at all. Keyboard access within the event table works (except for the close box in the top-right corner), but since the pop-up table cannot be produced through the keyboard, is probably of little relevance.
As an alternative for keyboard users, the links on each date lead to separate pages providing equivalent event information.
The keyboard focus on calendar dates just uses the system focus (dotted outline) and much less pronounced than the mouse focus, which inverts colours.
Once moving the mouse over a date has brought up the corresponding event table, a timeout starts that will hide the table after 6 seconds - just when users have begun to take in the events displayed. There is no option to turn off this time limit.
The dynamic display of event tables employs a small time lag to retain the table currently displayed should users decide to move the mouse over to the table, for example, to link to more information about the events. Without this time lag, the mouse travelling over other dates would immediately bring up other event tables for those dates.
While the time lag trick may work for young and competent users, it creates a real problem for aged and inexperienced users or users with motor deficiencies. It will be frustrating for them to experience that the events they have brought up for a chosen date are replaced by those for another date as soon as they try to drill down to them. While one could argue that it is easy enough to just click on the date instead to bring up a separate page listing the same events, the problem is that the pop-up action "saturates" users' expectation and will prevent many from realising this alternative option.
With CSS on, tabbing through the calendar does not bring up the event tables, so there is probably no difference between what is delivered to sighted keyboard users and screen reader users. The event tables are hidden with the CSS property
display="none", which means that screen readers will ignore them. For sighted users using their own or no style sheets (admittedly a small group), the long overview of events is poorly structured since it does not use headlines (the respective dates are merely shown in the tables' caption element).
While the WUK calendar seems quite successful in giving mouse users a quick overview of event information on a single page, the same information could have been displayed for keyboard users. At least, the site takes care to offer keyboard users equivalent information on a separate page.
The dynamically displayed event tables create significant problems for aged or inexperienced mouse users or mouse users with motor deficiencies. The fact that the event table is not adjacent to the date necessitates a time lag to 'bridge the gap', a trick likely to confuse or fail many users. The automatic time-out on the event table display is counterintuitive and should be abandoned.
The following tips summarise good practice for accessible calendar design.
preelement takes over the formatting of the matrix are not recommended since they make it hard for screen reader users to associate days with dates.
th) and content cells (
td) for proper semantic mark-up. Clearly, the (abbreviated) days across the top function as headers for the date numbers below, so they should go into
thheader cells while the date numbers go into
captionelement as a descriptive identification. The
captionelement has in the past been difficult to style consistently with CSS and has therefore often gone unused. It may also be redundant if a headline is already used to aid discovery of the calendar. In cases that also use the table's
summaryattribute which screen readers generally read, the same information may be read out three times!
abbrelement inside the header and stick the full day name into its
titleattribute. The problem is that it is down to individual screen reader settings whether abbreviations will be resolved - it does not happen by default.
abbrattribute of the header cell itself would seem more elegant, but unfortunately the current versions of the screen readers JAWS and NVDA do not render the expanded text, independent of the chosen settings for
Thu<span class="invisible">rsday</span>will present the abbreviation "Thu" on screen and read out "Thursday" to screenreader users. The advantage is that this will happen by default. However, care must be taken not to use the CSS property
display="none"to hide the text because then it will be ignored by screen readers. Instead, CSS should be used to position the invisible text outside the viewport.
Many thanks to Marco Zehe, Timo Wirth und Tiffany Wyatt for the instructive comments.