Data table for events?

[jasonkiss]

Visually, the events are presented as a table. There's some merit, I think, to marking them up as tables, possibly with a table for "Today", and one for each day or period (e.g. next 30 days), with just three columns: date & time, event, location. Of course, while there are "responsive tables", these can get a little messy and weird, esp. for screen reader users, but it's been a while since I looked at the browser/screen reader ramifications of such. I suspect things are a little better than they were then: http://accessibleculture.org/articles/2011/08/responsive-data-tables-and-screen-reader-accessibility/

[jamesmacfie]

Commenting here on what we talked about the other day, @jasonkiss , are you still of the opinion that tables are the way to go with coding these up? Ora are you leaning towards the concept of list items with child spans spacing out the different attributes of the event?

[jasonkiss]

A list is a possible option. But then what information should come first in each list item? Based on the current visual presentation, the first bit of information is the date and time, then the event title, followed by location. It occurs to me that reading through a list with a screen reader would be a little tedious, if you have to hear the date and time for each event before you get to hear the event’s title, which is what I suspect one really wants to hear first. In that case, would it be better for each event list item to start with the event title, then the date and time and location? Of course, with CSS, the current display where each event is displayed as a row with date and time first, followed by event title and then location, can be maintained, even if the order of those elements in markup is different and better suited to screen reader users. Although, ideally, visual presentation will match source order, though this isn't always crucial.

I passed these ideas and three examples of markup by three blind screen reader users. One of the examples was a data table representing the current visual presentation. The other two used an unordered list, one with the event title first, the other with the date and time first. Here are the comments I received:

USER #1 Firstly, all three examples were perfectly accessible to me using JAWS and IE - haven't tried on a mobile device yet.

In terms of the information which is presented first, I always think that is very much a matter of personal preference, which is why I like your suggestion of using the table to move through the column of preference, if that is possible from the device you are using. Personally for instance, I want to know when my next appointment is, then I want to know what and where it is, so your latest default works =particularly well for me, and with the two list options supplied, I preferred the one which placed the date/time information first.

Of course, there are absolutely times when I am wanting to know when the next meeting of such and such an event is, in which case then I would be interested in the actual event information being displayed first and then the date and time, but for me these tend to be exceptions, and so would hope that the table format would work.

I'm predominantly interested in what my week/month currently looks like in terms of appointments as it is then easier for me to slot in additional appointments, if, say, I know there's a space between 11am and 2pm on Wednesday, than it is if I know there's a space between the planning meeting and the teleconference that same day.

So, for me, I'd always prefer a calendar that can show me my filled time-slots first, whether that be in a list or a table format. What I'm sure about though is that other people will prefer the opposite!

I suspect most of us would agree though that seeing a day of hourly slots, regardless of whether they are filled or not is just painful.

[FOLLOW UP] I've now checked the Table version on my iPhone. This worked really well for me: I was able to either go through the table cell by cell if I wanted, or (and this is what I'd do usually) set the Rotor setting to Rows and then just navigate down my chosen column.

Very nice and efficient.

USER #2 I agree with [USER #1] that it is a matter of personal preference.

As a screen reader user, I prefer most of all the event list - date first. This is because for me, it's more important to know first the "when" before the "what". And, the list, to me, is easier to navigate, compared to the table version.

USER #3 I like the second one, the list with the event first, then the date. The table is ok, and readable, but I found it a tiny bit slower. I’ve not tested this with Jaws.

It's interesting feedback, and while it's hardly a representative sample, the fact that each of the three users prefers a different approach is telling.

I think that there's still value in the table approach, especially since, assuming that all users will want to sort events by date or time or title or even location, the table approach provides a pretty conventional pattern. But, as I noted before, on a small screen the table becomes a problem for sighted users because it is difficult to fit the three columns (date/time, event, and location) into the small viewport. While it is possible to change the display of the table in a whole number of ways for a narrow viewport, some of these can, or at least used to, have effects on some screen readers in certain browsers. Would need a little testing of the best way to do a responsive table, but part of me thinks this is the best approach. It is, after all, how the content is visually presented.

If a usable display that’s easily transposable across different devices and viewports and still accessible can't be made to work, that leaves us with a list, which, for all three users, worked fine and was accessible. In the case of the list, two of the three users preferred the when before the what.

[jamesmacfie]

From a dev point of view, the list is certainly the easier option because tables can be a bitch to work with, and the fact that the table wasn't overwhelmingly a more desirable option says to me that the list is the most flexible layout to work with. That's not to say that we shouldn't entertain tables, but being pragmatic about dev time vs layout flexibility is a consideration.

And if the when before the what is, from that small sample, what our data tells us then we should roll with that. None of this code is necessarily permanent anyway and can change if other data comes out telling us that a different approach is preferred.

Fantastic response, by the way.

[jasonkiss]

Cool. List with when first sounds reasonable, then.