I'm writing this blog post for at least three reasons:
- I'm often asked whether Doodle is accessible to screen reader users.
- I'm often a participant in meetings that (a) are scheduled via Doodle, and (b) include blind participants.
- I think Doodle's approach to making their interface accessible raises some interesting questions.
First, in case anyone is unaware, Doodle is a free website where people can compare available dates and times for meeting, without everyone having to share the same calendaring system.
The main interface is a table, where each row represents a participant and each column represents a particular meeting time on a particular date. Hey - what I just said could be included in a summary attribute on the <table> element, but Doodle instead is using the title of the meeting as the value of its summary attribute (in my example, summary="Our important meeting").
The table is also lacking key markup that is typically recommended for making HTML tables accessible. All of the column headers are marked up with <th> as they should be. However, there is no scope or id attribute on these <th> elements, nor is there a headers attribute on any of the <td> elements. This markup helps to ensure that screen readers correctly identify the relationships between all the tables' parts (for example, which headers go with which cells). For methods and techniques, WebAIM has authored an excellent tutorial on Creating Accessible Data Tables.
If a table includes accessible markup, screen readers will typically announce the new row or column headers as the user navigates into a new row or column. Screen readers typically don't announce this information for every cell, because if the user hasn't changed rows or columns they probably know where they are. If they need to be reminded, they can request this information from their screen reader with a keystroke or two.
Since Doodle doesn't include any of the HTML markup for explicitly associating headers with data cells, there's no guarantee that screen readers will correctly identify those relationships. However, I don't think that was an oversight on Doodle's part - I think it was a conscious decision. Here's why:
Doodle's table contains a form. Forms, like tables, have their own accessibility requirements. The most common and critical requirement is that all form fields should have <label> elements. For sighted users, labels are usually obvious. If there is a text prompt, it's usually positioned near the field so sighted users understand that it accompanies the field. If there are no text prompts, that's usually because there are other visual cues that make it obvious what a form field is for. However, blind users don't have access to those visual cues so form fields need <label> elements that are explicitly connected to the fields they represent.
Each checkboxes in the Doodle form has a <label> element that includes the full date and time (e.g., "Wednesday, June 1, 2011 9:00 AM - 10:00 AM"). They labels are positioned off-screen using Cascading Style Sheets (display:block; position:absolute; top: -999em) so they aren't visible to sighted users, but screen readers still read them. With so much detail in these labels, the user is absolutely certain of which dates and times they're checking, even though the accessible table markup is missing.
If a screen reader user wants to check and see who else among the invitees is available at particular times, they can do that too. Each table cell is filled with an image (a green checkbox signifying available, or an empty pink box signifying not available). Each of these images has an alt attribute that includes the name of the person, the date and time, and a one-word declaration of their availability (Yes or No), like this: alt="Jane Shmoe, Thursday, June 2, 2011 9:00 AM - 10:00 AM: No."
So to summarize, every cell in the table contains all the information a user could possibly need, using either alternate text on an image, or a hidden label on a form field. This approach makes row and column headers irrelevant.
I reserve judgment on whether this is the best approach. The biggest problem I see is that perhaps there's too much information. Users have to listen to far more detail than they would if accessible table markup was applied in conjunction with less detailed alternative content in each cell. To give sighted users a sense of how cumbersome this might be, here's the same table with CSS and images both turned off:
Imagine having to listen to all that information. On the other hand, the comparatively verbose approach that Doodle is taking is more precise. There's no requirement for users to piece together information from multiple sources (e.g., headings and labels or headings and alt). Maybe this is better for users who are less skilled with their screen readers. Any opinions? Please comment.
Doodle Mobile
Another option for screen reader users is to use the mobile version. If a user requests a Doodle URL via a mobile web browser, they are automatically redirected to the mobile version, which is ultra clean and simple. It's just a form with checkboxes:
Unfortunately Doodle neglected to add accessible markup to the mobile version (most notably, <label> elements are missing). However, from my tests it seems to work fine with VoiceOver on the iPhone, as well as with JAWS if a user opens the mobile version in a non-mobile Windows browser.
The mobile version doesn't allow users to see which dates and times other participants have selected, but some users might happily sacrifice that for the comparatively simple interface.
The mobile version can be accessed in a non-mobile browser at m.doodle.com. However, it's not as easy as you might think to convert a Doodle URL to its mobile version. To do that, you need to add "mobile/participation.html?pollid=" to the URL, after the top-level domain and before the Doodle ID. For example, let's say somebody sent you a Doodle link like this one:
Here's where you'll find the mobile version:
Did you say Doodle's table has a summary attribute?
Why yes, I did. As implemented, it doesn't provide a summary of the purpose and structure of the table, which is what the summary attribute was designed for. However, it could very easily be improved with something like this:
<table summary="In this table, each row represents one participant and each column represents one proposed meeting date/time. Participants appear in the order in which they submitted their available times. The bottom row of the table is your row, and includes one checkbox for each of the proposed meeting times.">
This summary can help screen reader users to know what to expect as they enter the table, and sighted users don't need that information. Unfortunately, the summary attribute has been dropped from the HTML5 specification, and HTML5 is about to go into "Last Call". But that's a topic for another day...
No comments:
Post a Comment