Thinking Calendar and Schedule Accessibility

One of the trickier items to make accessible is the calendar (and the related concept of the schedule grid). There are a few reasons for this.

Calendar/Schedule Pitfalls

Typical problems include:

1. Calendars/Schedules are generally presented in tables…and tables are always a challenge
2. Date Finders for forms are often presented as calendars in pop-up windows, which can also be bad for screen reader users.
3. Designers often merge cells, making the table complex. Does one event cross multiple days or one TV show last 2 hours? It could be presented as a line crossing cells. Once cells are merged it’s difficult to get a table to be coherent even in the best screen readers. In Google Calendar, it may be difficult to determine when a date is in Calendar view
4. Color coding also prevalent in calendars, but this causes problems for screen readers and color deficient users.

Tip 1: Can it be an Agenda?

The first issue to consider is – does your site actually need the calendar grid? One user asked me if a calendar was really empty or not working. It turned out that there were not any events happening that month (it’s summer people!).

If your organization has relatively few events, is it worth the bother of accessifying a calendar? A list may be more straightforward. Not only is a list a dates generally more accessible, but it displays all the events in one text block instead of forcing users to browse between months.

See the example below:
Note: Some calendar systems now include an “Agenda View” which can help users view events.

Tip 3: Move Date Picker to Edge and Make Optional

For many forms (e.g. hotel reservations), a date picker which opens a mini calendar can be useful, but it can also interfere with screen reader operation. You can look for accessible date pickers online, but here are some simple tips to consider:

1. Give users the option of entering a months and dates manually. These are simple entry fields which can be easy to code for screen readers. It also serves those who already know the date they need and don’t need the date picker.
2. It’s probably better to put the date picker after the date fields.
3. You want to ensure that the date picker can be tabbed/moused over without opening it. For forms, it is generally recommended to code any submit/open actions as a separate button requiring a definitive click or RETURN so that screen readers don’t trigger actions by mistake.
4. Similarly, if a user chooses to open the date picker, they should be able to control when it closes (with Control+W functionality for keyboard users). Closing it when the mouse moves off it is not enough control.

Tip 3: Simplify Tables: Calendar

A common design in many calendars which can be tricky for screen readers is to merge cells in the first row for the month. That means that the days of the week are on the second row and this can make reading calendars challenging for users on screen readers.

Another issue is that dates may be one one row and events on another. Again, this means that a screen reader user has to work more to match an event and they date

Here’s one example of an inaccessible calendar.

Here is how I would fix this table:

• First, I would tag the month as a CAPTION to avoid merging cells. This also puts the days of the week as the first row, which can be tagged as headers. This will allow screen reader users to more quickly identify the day of the week
• Second, I would ensure that the dates and events are in the same cells. You can use CSS to format numbers distinctively.

WCAG 2.0 Presentation

Tip 4: Simplify Tables: TV Schedule

Below is a classic online TV schedule. Note that cells for long programs are merged which means that screen readers may have a difficult time announcing the proper start and end times based on the times in the header.

Now I will be the first to admit that row spans are very handy from a visual perspective, but I also know how much it difficult it can be for a screen reader to parse. In the worst case scenario, a user may not be able to find the start time after 8:00 Pm.

There are several possibilities to fix this table. One is to add id and headers for each cell, but IMHO, this is a major pain to program and it doesn’t work in all screen readers. Whenever possible, I fall back to simple tables with headers AND no merged cells

So…A simple table solution would replicate the program name in the 30 min slots (and some schedules do implement this). Ironically though, it may not be very usable for either visual or screen reader users.

This is accessible, but it does mean that some titles are repeated (a movie like Legally Blonde is repeated in 4 cells). It looks weird visually and is probably even more awkward in a screen reader.

In this case, it could make sense to maintain the merged cells, but I would recommend including start and end time in each cell (e.g. “Legally Blonde: 8-10PM”) I would also make sure that the SUMMARY tag indicates the presence of merged cells.

I am not sure if this is the optimal solution, but it has to be an improvement of the original table.

FYI – If you were really ambitious, you could replace the table with a set of lists where the list items of each network included the start/end time and had a width adjusted for program time…but it would be a trick to debug.