So the other day I went over to the local BofA to deposit some checks and I saw that they had some brand new ATMs.  Now, with the really old ATMs, you would put your checks in an envelope and type in the total amount of the deposit. And with the successors to those ATMs, you would insert your checks one at a time, sans envelope, and you would then verify the amount that the ATM automatically read off those checks with its internal scanner.

With these new ATMs, however, you can insert all your checks at once, again without an envelope, and the scanner will deal with them all for you.  Reduces paper waste; cuts out a few steps; sounds good, right?

It would be good if the brand new ATM that I used didn’t have problems scanning the amounts off every one of my checks.  Every single one.  And I would have just corrected the amounts at the verification stage, but the on-screen images of the checks were too small for me to read.

The only thing I could do was cancel the entire transaction, get my checks back, try to remember the amount on each one, and start over.  These weren’t big checks, maybe totaling a few thousand dollars, but trying to remember four several-digit numbers is surprisingly hard to do!

Fortunately — or perhaps not — it didn’t matter.  When I inserted the checks again, the ATM seemingly scanned them all without problem — and then showed me the calculated total: $82,550.25.

As nice as that would have been were it true, I cancelled the transaction yet again.  It’s then that I noticed the logo on the machine: Diebold, it said.

The session is on Saturday at 11am.  Drop by and check it out if you’re attending.  For those who can’t make it or didn’t register before alll the spots were gone, I’ll post my notes here.

Unfortunately, most digital calendars don’t provide a year view.  For instance, Google Calendar lets you look at a day, a week, four days (why?), and a month — but not an entire year.  The last I checked, Outlook does the same (although with a more helpful five-day view, rather than four.)

When calendars do provide a year view, it’s usually just the “month view” for each of the 12 months, compressed onto a single page.  For example, here’s the year view for Yahoo Calendar:

Oddly, Yahoo Calendar doesn’t seem to show events on this view — it’s simply a selector that takes you to the “week view” that you click on.

But even if you did see some sort of indication of booked events on this view, it wouldn’t be so easy to read.  Events spanning multiple weeks or months would wrap too many times. And you’d have to look pretty hard to figure out which weekends were booked and which were open.

It’s not a terrible sin, but it’s not the most usable way to visualize a year’s events.

So what’s better?  I’ve been searching for a couple years and the only really good visualization I’ve found so far is in an Outlook plugin from an Australian company called Planet Software.  Their Outlook Year View plugin adds an option to a standard Outlook calendar that lets you see all your events in the following style.

I can’t speak for the plugin because I don’t use Outlook, but I love the way this visualization maps out each month’s events linearly.  Stacking the months lets you take in the entire year in a comfortable left-to-right, top-to-bottom format.  And staggering the months aligns all the weekends, so you can quickly see what’s still free.

The moral here is that even something so familiar as a calendar can be improved upon.  Tufte would be proud.

The Myths

Myth 1: You must provide alternate text for every image on a Web page, via the alt attribute.

Using the alt attribute to describe an image for visitors with visual impairments is great — except when you start describing images that don’t provide much additional information to a page. Then, you could actually be making the experience worse for visitors who are using screen-reader technology, like Freedom Scientific’s JAWS, which reads the text on your Web site in a linear fashion.

“Many developers assume that blind users will want to know details about every graphic,” said Jane Berliss-Vincent, Director of Adult and Senior Services at the Center for Accessible Technology. “However, most blind users I’ve worked with are much more interested in being able to traverse the page quickly, and dislike having to listen to large amounts of text that they may deem irrelevant.”

Berliss-Vincent recommends the following guidelines for developers:

• Provide some type of text description for graphics that convey information — for instance, bitmapped text and charts. You can provide this information via alt attributes or in the body of the page, such as in a caption — but not both. If you provide a caption, just include a blank alt attribute (alt="") in your IMAGE element; otherwise, screen readers will speak both the attribute and the caption, which is redundant.

• Images that are used purely for presentation and decoration should be inserted into the page via cascading style sheets (CSS) or else you should provide a blank alt attribute (alt="") in the IMAGE element.

• Use your best judgment on graphics that fall somewhere in between, taking your cues from the context of the page. For example:
  • On U.S. Vice President Dick Cheney’s Web site, a stock photo of him would probably merit a blank alt attribute.
  • On a satiric Web page that says, “Here’s something you don’t see every day!” alongside a photo of Cheney smiling — with no other description — an appropriate alt attribute would be alt="Dick Cheney smiling".
  • On a page that covers sartorial trends among vice presidents, use a blank alt attribute if Cheney’s clothing is described elsewhere; provide fewer than 80 characters of alt text if you are only describing one feature, like “Dick Cheney’s tie is red with purple spirals”; or provide an inline description (or use the related longdesc attribute) to describe his entire outfit in detail.
• No matter what the graphic, short alt attributes are usually better than long ones and should not exceed 80 characters.
• At the least, a blank alt attribute is necessary in every IMAGE element. This is critical for meeting accessibility requirements because, without it, many screen readers will speak the location of the image, which is an impediment to users trying to scan a page quickly.

Myth 2: You must fill out the title attribute for every link.

Some Web browsers display the text of the title attribute as a “tool tip” — a little box that pops up when a user puts the mouse cursor over the link or other element where a title has been specified. Unfortunately, this has led many Web content developers to get lazy about writing clear and unambiguous link text. (After all, why rework a sentence to make it clear where a link points to when you can just provide additional information about the link in a tool tip?)

To make matters worse, Web usability expert Jakob Nielsen tied the title attribute to accessibility when, in a 1998 Alertbox column, he stated incorrectly that “auditory browsers will read the text aloud and not display it visually.”

In truth, many users of screen readers don’t enable the option to access the title attribute information, according to a survey of title attribute access by Web Accessibility Consultant Steven Faulkner. Likewise, visitors who use screen-magnifying technologies may not be able to see the entire text of the title attribute when it pops up in a tool tip.

As Faulkner points out in a related presentation on the title attribute, the title has its place — but the most accessible thing you can do for a link is make sure that the link text is well written.

One way to test the clarity of your link text is to imagine all your links listed sequentially. (Many assistive browsers, like JAWS, will actually list your links this way to help users navigate your site more quickly.) If you notice that several links that appeared fine in the context of the Web page now seem ambiguous, go back and make them more descriptive. For instance, a link to “article” may be better as a link to “John’s article about accessibility.”

Myth 3: You should only use TABLE elements for displaying data and never for laying out the components of your Web page.

Before Cascading Style Sheets (CSS) offered a way to lay out Web pages independently of the content itself, innovative Web designers figured out that they could use HTML tables to visually display content in neat rows and columns. Problem was, many assistive technologies at the time were designed to treat tables in their originally intended manner — which was to present tabulated data.

The developers of many assistive technologies have since upgraded their products to cope with most table-based layouts. For instance, JAWS by default ignores any tables that have just one row or just one column; and users can further customize these settings according to their own preferences.

Still not convinced? The Web sites of the Center for Accessible Technology, Freedom Scientific, the American Foundation for the Blind, and the American Disability Association all use tables for layout.

Now, this is not to say that you shouldn’t bother to learn how to lay out Web pages with CSS — because you should. But if you’re maintaining a number of existing Web pages that rely on table layouts, you have more leeway than you might think.

Myth 4: You shouldn’t use JavaScript on your Web site.

Many Web designers and developers avoid creating rich user interfaces with JavaScript under the assumption that the scripting language will foil assistive technologies. But when used wisely, JavaScript can actually extend the accessibility of a site.

For instance, JavaScript can be used to enable keyboard shortcuts that trigger certain actions on a Web page — an important part of making sites accessible for users who can’t use a mouse.

“That’s proof that JavaScript is not the culprit,” said Nate Koechley, Senior Engineer and Design Liaison at Yahoo. “The culprit is not thinking about all the different interface actions and the effects they have.”

By staying away from JavaScript, many developers and designers unnecessarily hold themselves back from using common user interface tools that can enrich a Web site, like sliders and pop-up calendars. However, as Koechley and Yahoo’s Accessibility Project Manager Victor Tsaran recently pointed out in a presentation on Yahoo’s experiences (3MB PPT), these tools can be accessible so long as developers adhere to Web standards, provide other means of input, and think carefully about how the tools will work.

A 2003 FAQ by Freedom Scientific offers these guidelines for ensuring that JAWS users will be able to access JavaScript features:

• The scripts must be activated by clicking a link or clickable item and the script dynamically updates the HTML source.
• The scripts should not update the page without user intervention.

Testing, Testing

The W3C hopes to clear up a lot of the confusion surrounding Web accessibility with the release of Web Content Accessibility Guidelines 2.0. Whereas the first version focused mainly on HTML WCAG 2.0 provides accessibility techniques for a broader range of technologies, including style sheets, multimedia, scripting, and applet technologies. The W3C will also provide supporting materials to help developers better understand the reasoning behind the new guidelines.

It’s unclear when the new version will be officially released, but until that time, Berliss-Vincent recommends that Web designers and developers continue to follow WCAG 1.0 — and to seek assistance from accessibility experts. “It is also crucial to involve users with disabilities in the Web site testing process,” she said. “Collect their feedback on what works and doesn’t work for them, and compensate them for their time.”

Koechley agrees that testing is critical to determining the accessibility of your site. “There’s no real substitute for testing and putting it in front of users,” he said. “You know how when you print out a map from a service like Yahoo Maps and there’s a disclaimer that you should ‘verify the directions with reality’? It’s the same thing here.”

Copyright © 2006 CompuMentor. This work is published under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License.

But the problem with one-size-fits-all usability guidelines like these is that they tend to overlook the fact that not all Web sites are created equal — or, in this case, that not all hyperlinks are equal.

When It Makes Sense: Links to Pages

Nielsen’s refrain makes sense when sites uses the traditional “page” model, which was the dominant model in 1996 when Nielsen originally warned about changing standard link colors.  In this model, selecting a link takes you to a new page of information.  When, as a visitor to a site, you’re presented with lots of links to lots of pages, it’s certainly helpful to be able to see which links you’ve already selected.

Forums, news sites, and other content-heavy sites are good examples of this.

Where visited link colors are helpful: Jakob Nielsen’s own useit.com:

Where visited link colors are helpful: Hacker News forums:

When It Doesn’t Help: Application and Persistent Navigation

These days, links don’t always point to pages of content — especially not when the links are in the context of an application. Likewise, links aren’t always in a sea of other links — they may be part of a clear set of links used in persistent navigation.

In the application model, the Web site (or part of it) is an application rather than a collection of pages.  Links on applications often trigger actions rather than accessing new content.

For instance, a photo sharing application might feature a link to rotate a photo, one to delete the photo, and another to get the original photo.  Changing the color of the “rotate” link after a user rotates the photo doesn’t impart any new information.  The user doesn’t need to know on subsequent visits that she has rotated the photo before.

If anything, changing the link color here could prove to be confusing because the user might question why one of the options — rotate — looks different visually than the other options.

Where visited link colors would not be helpful: Kinverge photo toolbar:

In persistent navigation, the links may point to content pages, but the limited number of options and the fact that they are constant diminishes the benefit of changing the visited link color.  And again, changing the visited link color here may even increase confusion.

Where visited link colors would not be helpful: Amazon.com navigation:

Visited link colors can make things even more confusing when you have a limited number of nav links and are already using a different style to indicate the visitor’s current position.  Using three styles for, say, five links creates visual clutter and makes it hard to distinguish what the different styles are for.

Where visited link colors would not be helpful: Clicky dashboard navigation:

It’s All About Context

This is not to say that all links on your site or application should be one color, or that visited link colors are only for content-rich sites.  But do you always need your links to show a “visited” state, as Nielsen would have you?  No.

The best solution is to pay attention to context. Chances are, any Web site you build these days is going to have a mix of content and applications, with some persistent navigation tying it together.  It may be that what works best for your audience is to give each of these classes of links a distinct style and to only set a unique visited color for the content class.

Now, that may violate another of Nielsen’s guidelines (regarding consistency), but that’s an argument for another day.