The type of questions you ask a client have an influence on the type of answer you’ll get, and are influenced by the comfort level of the client. This applies on many levels, but here, I want to focus exclusively on questions as part of the initial discovery phase as part of a design process.

Eris Free makes some interesting statements in her latest post “Designer != Psychic“. She outlines a bit of frustration in dealing with clients – in particular with their contribution to the design process – no doubt, this is something many desigers face in their work.
Continue reading The Art of Questioning your Clients

Many of the techniques we employ as developers to make our web sites more accessible result in hidden information that may only make them more accessible to a small portion of users rather than more accessible to everyone. Published over at WATS.ca, Contradictions in Accessibility: Hidden Information examines how some accessibility features built in to HTML could be paired with low tech approaches to enhance accessibility.

Many of the techniques we employ as developers to make our web sites more accessible result in hidden information that may only make them more accessible to a small portion of users rather than more accessible to everyone.

(X)HTML provides many ways of providing extra “information” about various elements on the screen: title attributes for acronyms and abbreviations; title attributes for links; longdesc for images; alt text for images; summary attribute for tables; to name a few. While the use of these attributes is encouraged by many (including ourselves), and deemed an improvement to accessibility, using them does not always improve universal accessibility.

Common to all of the above “accessible” and recommended techniques is that the information they provide is hidden from view and is only available with some effort. As authors we need to consider low-tech solutions in addition to the solutions that we implement that technically make our documents more accessible to everyone.

Long Descriptions

Long descriptions for images include a URL in the longdesc attribute to indicate an alternative representation of the information contained within the image. Often these are complemented by hidden or otherwise obscure “d” links. The contents of the longdesc attribute, however, isn’t readily available to users — they either need to secondary mouse click, and select properties, or Longdesc, or some use some other method in order to get at the data.

A screen reader user has the advantage that their software will tell them that a long description is available. But what about the rest of us?

Perhaps it would be more universal to consider a low tech alternative – simply including the text based format in the same page. That way everyone can access it without having to go through extra clicks or other manipulation.

We might consider providing a full text link (instead of a d-link) to the image and its description in the text. This is more universal and will be available in all technologies instead of only those technologies that support longdesc. In cases where the image contains data (such as pie charts or graphs), we’ve seen longdesc links that lead to a text version of the same data — in list or tabular format. We even provide an example of this on our site: Demonstration of the LONGDESC attribute and the “d” link. Why not include the table or list of data in the original page?

Yes, we do recognize that in some instances the tabular data may be more appropriately placed on a separate page. We should at least consider using the low tech option might be better.

Title attributes

Title attributes are most commonly used on links to provide “advisory” information (or in some cases, commentary) about the link. We see them all the time for people providing a “Quick Links” section on their blogs. We see this technique used in Dave Shea’s Mezzoblue dailies, Mark Pilgrim’s b-links, Anne van Kesteren’s HREF, and Simon Collison’s Logical Linkages, among others. In many of these cases it is an exercise in saving space, being subtle and maintaining a clean, crisp design. The problem is that the titles are hidden until your mouse hovers over the link.

To compensate for this, we see Mark Pilgrim providing a good example in his b-links Archives. If you view his b-links archives for June 2004, you’ll notice that in this version of his b-links, he has opted to display his commentary on each of his links in plain view, rather than hiding it in the title attribute. A nice, low-tech alternative solution that is accessible to everyone, and a reasonable compromise.

Another issue with hidden title text remains – titles are not shown as a “tooltip” when the links received focus via the keyboard. So much for device independence. Yes, this is the fault of the browsers. (Note to browser makers – can we fix this please?) Until this is addresseed, consider that the text you are stashing in the title attribute may be better placed elsewhere – perhaps as regular old text. This ultra low-tech, highly-accessible solution provides the information to everyone. Roger Johansson of 456 Berea Street uses this technique in his Quicklinks section on the main page of his site.

Summaries on tables

This suffers from many of the same problems as the previous examples. Accessibility advocates (again, including ourselves) advocate the use of the summary attribute. The problem is that while it technically enhances accessibility, it doesn’t expose the potentially useful information to others. Clearly the decision to place the contents of the summary attribute in regular body content (either as a heading, or perhaps as a simple text description) before the table is dependent upon context, and upon the text that you are actually placing in the summary. However, it is still worthwhile considering this low tech approach — it may be useful to users with cognitive disabilities or others that are viewing the content to get the quick summary of the trend that is displayed in the table.

What can we do?

There are a number of solutions for these hidden items:

1. We can encourage and wait for browser makers to provide mechanisms to expose these hidden alternatives (eg., Internet Explorer still doesn’t support longdesc, except for those that install Jon Hanna’s longdesc linker)
2. Individual site authors can provide a preferences page so users can provide their preferences (i.e., images on/off, display long descriptions, Flash on/off). This could be saved via a cookie on the users computer. Christian Heilmann has an interesting implementation demonstrated at Learning to Let Go
3. Individual site authors can make choices about how they code their documents by realizing that just because something is technically accessible doesn’t always mean it is functionally accessible. (OK, the way I worded the third option, really makes it obvious which choice I’m going to advocate…)

Asking the browser makers to make their user agents better is a good start. It is what we expect – just as we as authors have to do our part to follow the spirit of WCAG. Unfortunately waiting for user agents to improve doesn’t deal with the here and now.

Some authors will choose to employ some type of preferences page. Perhaps Christian might add an “expose all hidden information” option to his demonstration? While this may seem to work in principle, I still believe it is a bit much to expect users to set their preferences on each web site they visit. Setting browser preferences are usually buried deep within multiple menus and modal dialog boxes where individuals either can’t or won’t change them, simply because they don’t know the controls exist.

By no means are we suggesting that we shouldn’t use all of the accessbility enhancements that are provided to us in HTML/XHTML. We are suggesting that in addition to providing extra advisory information hidden away, that as authors we simply consider other low-tech ways to support universal accessibility. After all, accessibility isn’t just about screen reader users…

Have kids. If that won’t convince you that web sites should be accessible, I don’t know what will.

I’m a new parent again – Kampbell, our third child, arrived just over two weeks ago. We are truly blessed to have such wonderful children. However, the more I try to do, the more I realize that in some ways children are just like some form of temporary impairment… Here’s a half-serious half-joking look at why… ;)

Continue reading Children and Accessibility: It matters

Most standards-based web sites don’t need to include tabindex for their links. When they are included along with other techniques such as skip to content links, they can hinder functionality and usability. Published over at WATS.ca, Contradictions in Accessibility: Keyboard Usage and Tabindex examines what can happen when two techniques designed to help with accessibility are used together.

This article is also available in German, translated by Tomas Caspers.

One of the basic tenets of building accessible web sites is designing for device-independence. The most common interpretation of device-independence is to ensure that keyboard functionality is available for all users – both those that must use, and those that choose to use, the keyboard as their primary input device rather than a mouse. Further, many assistive technologies for people with mobility impairments work with the keyboard directly, or through emulating keyboard functionality.

In an effort to make their pages more accessible, many people (not all) attempt to implement both skip to content links along with tabindex.

So, what can happen when these two techniques are combined? Consider a site with a skip nav link with a tabindex of 1. Immediately following the skip nav link is the site’s global navigation: Home, About Us, Services, and Contact with a tabindex of 2,3,4 and 5 respectively.

A keyboard user tabs to the “skip to content” link (tabindex of 1) and activates the link to take them to the main content. Then they press tab again, and are taken to the link with the next tabindex (the home link, with tabindex of 2), placing them back in the site’s navigation bar. In many cases, when tabindex is used on links it effectively renders the skip to content link useless.

Oops.

This behaviour does depend on the user agent being used. Quick tests show that:

• Gecko based browsers display the above mentioned behaviour (both Mac and PC)
• IE 5.1 (Mac) exhibits the behaviour outlined above
• IE 6 and 5.5 (PC) both pick up the next tabindex in the content area.
• Opera 7.x allows you to follow the skip to content link. Tab again, and it places you back on the skip to content link again and then lets you continue from there.
• Netscape 4 (sure, why not…) performs the same as the Gecko browsers

We’ll continue to add to this list as we continue testing.

Web Content Accessibility Guidelines

In this case, authors are simply using two techniques found in the Web Content Accessibility Guidelines.

WCAG Checkpoint 13.6 advises developers to Group related links… until user agents do so, provide a way to bypass the group. This has lead to many sites using “skip navigation” or “skip to content” links, and are usually the first items found in a page. This is a useful feature.

WCAG Checkpoint 9.4 states Create a logical tab order… For example in HTML specify a tab order via the tabindex attribute, or ensure a logical page design.

The problem really occurs when authors implement tabindex in cases where it really isn’t needed. As with most development work, some simple accessibility testing would eliminate this problem almost immediately.

Who is responsible?

As always, we all share responsibility for accessibility. At this point there is no concensus amongst browser vendors in terms of how this should implemented and the User Agent Accessibility Guidelines provide no guidelines on how to implement this functionality.

People also have to make appropriate choices in terms of the browser they use, and they could select one that behaves in an appropriate manner. In this case, it would appear that Internet Explorer is closest to the desired behaviour: activating a same page link (such as a skip to content link) moves the focus to the target, and continues from there, rather than return to the next tabindexed value like a Gecko based browser.

This leaves the authors. The good news is that Checkpoint 9.4 of WCAG says “For example, in HTML, specify tab order via the “tabindex” attribute or ensure a logical page design.”

Now that many developers and designers are moving forward, and producing standards based, tableless layouts, in most cases they are creating pages that have a logical page design with a logical tab order. Generally authors don’t need tabindex with these types of layouts as the technique can cause more problems that it solves.

One thing I’ve missed with WordPress is having nicely defined Link relationships between posts. All it takes is a little <link rel="next" title="" href="" /> or <link rel="prev" title="" href="" />.

Here’s a Link rel Plugin for WordPress. Still version 0.1, so don’t come after me if it doesn’t work properly yet. I’m still testing, and adding in various other relationships beyond just next and prev… ;)
Continue reading Link Relationship Plugin for WordPress

One of the fundamental conventions on the web doesn’t live up to Web Content Accessibility Guidelines. Published over at WATS.ca, Contradictions in Accessibility: Links and Default Link Styles asks the question:

Why are visited links and unvisited links, by default, distinguished by colour alone?

By convention on the web, links and visited links are a different colour. Jakob Neilsen has recently discussed this in his May 3rd, 2004 AlertBox Link Color where he concludes: Using different colors for visited and unvisited links makes your site easier to navigate and thus increases user satisfaction.

Most mainstream browsers have this behaviour built in to them by default. But what about WCAG Priority 1 Guidelines, Checkpoint 2.1?

Guideline 2. Don’t rely on color alone.
“Ensure that all information conveyed with color is also available without color, for example from context or markup.”

Oops. Many may say that this won’t impact much of the population — only those with difficulty distinguishing colours, those few people on a monochrome monitor, or the few with an RGB monitor on the fritz that isn’t displaying properly. Regardless, we can’t possibly know everything about the people visiting our sites, so perhaps we need to err on the side of caution? We still ask the question: Why are visited links and unvisited links, by default, distinguished by colour alone?

We’ve modified our CSS to style links in the content so that they differ in colour and in font-weight: we show unvisited links as a blue colour and a font-weight of bold, and visited links are different colour and have a font-weight of normal. Both types of links in the content of our documents are still underlined. We were comfortable doing so because it had very little impact on our current design.

Other strategies

Two others we’ve noticed doing something similar recently are Simon Collison and Shaun Inman. Shaun displays visited links in his “Recent” links with a strikethrough. Simon’s technique outlined in his article “Ticked-off? Visited Links How-to” accomplishes the same for links in his sidebars. While both have abandoned the convention of using colour to distinguish between visited and unvisited links (Simon suggests I expect Jakob Nielsen would shoot me on the spot), either technique could be particularly useful for site navigation links and could be adapted or modified to use for content links as well.

While displaying a visited link with a strikethrough may work, as authors we should be conscious of the potential conflict this may have with the rarely used <del> element that may render with a strikethrough by default.

Who is responsible?

As with most accessibility issues, there are a number different stakeholders with some responsibility. WCAG Guideline 2 says “don’t rely on colour alone”. But what about users and browser makers?

Users could do a few things to help themselves out. Setting a user stylesheet to mark visited links with a strikethrough, or with some other distinct style would help. Unfortunately, most users don’t know how to implement user style sheets.

The User Agent Accessibility Guidelines also provide some guidance.

Guideline 10: Orient the user
“Provide information that will help the user understand browsing context.”

Checkpoint 10.5 (a Priority 3 checkpoint of the UAAG) simply tells those creating user agents to provide information about whether or not the link has been recently visited, with no suggestions as to how this should be done – with colour or otherwise. The UUAG also suggest that these user agent preferences should be cutomizable.

So, a user could theoretically distinguish between visited links and unvisited links via browser preferences. At this point, most mainstream browsers allow for custom link colours, for visited and unvisited links but do not allow a user to change anything else about those links. The most notable exception is the Opera browser that allows a user to change not only the colour, but also what amounts to the “text-decoration” CSS property on links and visited links. Opera has had this feature since at least version 5 of its browser. Even if more user agents supported this feature, it is quite possible that users wouldn’t change their default settings.

So that leaves us, the authors to consider our options. CSS provides the tool we need to make distinction. Hopefully designers can implement strategies that enhance their design, and help accessibility at the same time. With designers like Simon and Shaun making contributions to both the design world and accessibility, we at least know that it can be done.

Yesterday I wrote about why I chose WordPress for v1.boxofchocolates.ca. I had my reasons – I like that I can drive the whole site with one template, that it is based on PHP, and that because of my experience with PHP there was a very low barrier to entry – no new language or syntax to learn.

Matt, the kind soul that he is, noted my entry on PhotoMatt, which prompted me to read a few other related entries over there.
Continue reading Choosing your sWord