Usability First

Mobile-friendly and accessible are 2 ways that many companies, product owners, and developers would love to describe the sites they build and contribute to. Usually, this is achieved by some form of remediation project, or 2 big epic stories in the backlog near the end of the list of priorities. To be fair, having the remediation project is sometimes a necessary evil; especially, if the site is at least 4 years old—the internet has changed a lot. For new projects, however, having an epic in the backlog for mobile strategy or accessibility is really an indicator of a growing problem the remediation project should also be trying to solve—a site that has some major usability problems.

What Usable Means

I recently read a post titled F*** You by Brad Frost. While I don't agree with everything Brad has to say in the post, it's a great read to remind all of us contributors to the web that not everyone is using an iPhone or the latest version of Chrome on a Mac to view our sites. Ultimately, you're most likely part of a business trying to make money so it's important you know your users and the technologies they're using—you can't make everything perfect for all variations of browsers, operating systems, and other technologies. However, if things like accessibility and mobile experience aren't even the smallest part of everything you do, you're building something that for some users is not usable.

Slice Things Horizontally

An old friend that's a very talented tattoo artist reached out through her network asking if anyone could help update her list of appointments on her web site built using Virb. The template she was using was simply listing all of her appointments in a 2 column list. Her goal was to make things a lot easier for her clients to look up their appointments, which are commonly made far in advance. She wanted a calendar view, which I agreed was a good idea, except that I didn't think a calendar view would be really usable on smaller mobile devices. I also wanted to consider users with disabilities.

So, rather than focusing on the mobile experience, or picking apart every aspect of a calendar with an accessibility lense, or simply trying to make the best damn looking calendar a tattoo artist could ask for—these are all vertical slices by the way—I decided on the amount of effort I'd put into updating the UI, determined the required features, and sliced up the work horizontally. For example, the current interation:

contains a calendar view

nothing fancy here; just your normal calendar arranged by year and month with days of the week headings

is usable on mobile devices

on any device smaller than an iPad, the calendar view switches to a date book view with only dates containing appointments—no frameworks, just simple media queries

addresses some accessibility concerns

the calendar uses a good heading structure, color contrast ratio is verified, aria-hidden used on days with no appointments, and each date read by screen readers contains the month, day of the week, and day of the month

Future iterations can be used to enhance the design, focus on specific mobile devices, or improve the navigation throughout the calendar to improve the experience for all users, including those with disabilities.

Check It Out!

You can see a snapshot version of the calendar at http://theaccessibleweb.com/examples/appts/index.html. I'd love questions, comments, and especially criticism.

There are a couple things about the demo I'd like to note based on some great questions and feedback from Dennis Lembree of Web Axe. The calendar is dependent on javascript being enabled—Virb heavily uses javascript templating; additionally, it was desired to keep the data entry process unchanged. Therefore, the calendar works by reading the DOM, building a new javascript object for the appointments, and rewriting the DOM. Based on the the feedback, I made sure that if javascript is disabled, the old DOM is visible along with a message to let users know the page is better viewed with javascript enabled.