Derek Featherstone Interview

In: Interviews

By Carolyn Wood

Published on February 27, 2006

Digital Web Magazine: Derek, one of your Web sites is named Simply Accessible, yet your popular talk at the 2005 Web Essentials conference in Sydney was given a 5 on the Geek-O-Meter scale—the highest rating. Using my keen powers of observation, I believe I detect a contradiction here.

Derek Featherstone: We geeked out for 50 minutes looking at code and examples (hence the 5). If you know your code—HTML, CSS and JavaScript—you can use simple concepts in completely new ways to make sites more accessible. I’ll be honest, many of the examples that I presented at Web Essentials required a pretty solid understanding of CSS.

Let’s not forget, though, that many Web sites could be made much more accessible if designers and developers used simple techniques, simply thought things through more carefully, and followed some very simple principles.

DW: Many people attempt to make their sites accessible by simply complying with items on a checklist. But when designers aren’t doing accessibility testing with real people they can end up with some misconceptions, can’t they? What accessibility myths have you encountered?

DF: There are loads. Here are two that I’ve seen in the past month or so:

• I would assume that the blind have their browsers set to not load images.
• Blind people don’t have JavaScript in their talking Web browsers.

As for the first one, while a person may use a screen reader, it doesn’t mean that they have images off—their vision may be good enough to make out certain things on the screen.

The second statement, involving JavaScript and accessibility, is the biggest myth I encounter. It has long been said that to make a site that uses JavaScript accessible, you must be certain that it works with scripting both on and off, and provide functional equivalents. However, that’s often more a question of interoperability than accessibility (not always, but often).

Consider that most (not all, but most) screen reader users are very likely to be using a fully JavaScript-capable browser—likely Internet Explorer—with a screen reader running on top of it.

So really, JavaScript on or off are two scenarios that we can deal with. What we still haven’t fully wrapped our heads around is how screen readers and other assistive technologies actually interact with scripting when things change in a page: How does a screen reader interact with the JavaScript you’ve written to show and hide part of your menu, or part of your content? How does a screen reader deal with a link that is injected into the page using unobtrusive DOM scripting techniques? What about when the text in that link is changed? And what about screen magnifiers? How do we let them know that something has changed far away on the screen if they aren’t able to see it because they have a magnified view of the page? James Edwards has done some extensive testing and published the results at Access Matters. Clearly it isn’t as simple as it’s been made out to be—JavaScript on or off is important, but it’s not the way to ensure that JavaScript is being used in an accessible manner.

DW: What strategy do you use for designing or evaluating the accessibility of a page or feature?

DF: I start with these four questions:

1. What information is presented?
2. What is the expected interaction?
3. How we do that semantically?
4. How do we get that information and/or functionality to everyone, regardless of ability?

For example, let’s look at tag clouds from Technorati. The tag cloud gives us a lot of information—popularity of each tag in general and in relation to other tags. People are likely to view the details for a specific tag or compare two or more tags to another. Representing that semantically can take a few forms. Not surprisingly, they’ve used an unordered list, and used nested <em>…</em> to signify relative weighting. Semantically this makes sense, but the weighting through nested <em></em> is only visualized through the CSS. So, how can we express that weighting to everyone—including those who can’t see the effects of the CSS? Providing a link to a version coded in an ordered list along with a numerical representation in plain text of the relative weighting would provide the equivalent functionality to everyone.

DW: If a Web design company is offering “accessible sites,” which tools should they routinely be using to test their sites?

DF: The essentials are: your brain (seriously), users to test with, the Web developer toolbar from Chris Pederick (for Firefox/Mozilla) and the Accessibility Toolbar from Vision Australia (for IE).

I start with “your brain” because accessibility isn’t a black-or-white question—what may be accessible to one person may not be to another. Human judgment plays a critical role in the process, and that comes from your brain, and your bank of experience.

I would like to add IBM’s aDesigner to the list—it provides some really nice simulations of various visual impairments including low vision and colorblindness, though I can’t really say it’s “essential,” because they charge for a product they don’t yet support.

Testing real users with disabilities using screen readers, magnifiers, voice recognition or other assistive technology (both hardware and software) is much more effective than doing it yourself. I would also recommend testing with screen readers such as JAWS, Window Eyes, or HAL (though some will disagree with me, I find that testing small bits of code with screen readers is very useful), and screen magnifiers.

The expense of screen reader software is often enough to scare people away from buying a copy. If you want to get a better handle on the concept of screen reading, then you might get a copy of IBM’s Home Page Reader. It is not the same as other well-known screen readers, but it gives you a decent idea of what screen readers do, and a better understanding of what the experience is like. You might also try recent versions of Opera that include text-to-speech functionality as well as basic voice command recognition. Just be sure that you don’t equate how things work in HomePage Reader or Opera with Voice with other full screen readers, as they work differently. If you’re using HPR or Opera with Voice, you’re generally doing it to learn more about how screen readers/voice browsers work, not for the minute details of how specific code samples are read.

Both of the toolbars I mentioned include features for working with images, checking for headings, alt text, and other specialties, such as a color contrast analyzer and other tools from Gez Lemon and other organizations, so they really cover a lot of ground.

While automated testing tools like AccVerify and WebXM from Watchfire are often criticized for their utility in testing, I find them very useful to get a quick overview of the sites I’m testing, especially larger sites. They can test large sites for the presence of alt text, labels and headings much quicker than I can, and they help facilitate the process of manually reviewing sample pages from the sites.

DW: You’ve mentioned that you provide an “orientation guide” page on some of the sites you design. Do you create one for every site? What are some items you might include?

DF: I don’t always create an orientation guide, no. But I consider it for specific cases. For example, if I were building something relatively unique like a framework for an e-learning course, or a new Web application, I would likely provide one. Of course most of the interface should be obvious, but that isn’t always the case. You might turn to a help section after you get stuck; an orientation guide strives to prevent you from getting stuck in the first place.

In an orientation guide for a Web application, for example, I might provide specific instructions for a screen reader user to adjust settings, or steps for a low-vision user to activate the zoom layout, or a statement that shows mobility-impaired users that they don’t have to click the radio button—they can just click the much bigger target that the label provides. I might also include instructions on how to make a drink called a Smiling Jerry, or stick a pint glass to their chin, but that would obviously be for a very specific audience.

DW: Such as an application aimed at Web developers, I suppose, or accessibility experts.

DF: Precisely.

DW: What’s the latest nifty accessibility technique that you’ve been using?

I’m using absolute and relative positioning a lot to do micro-layouts that are more accessible. By micro-layouts I mean that I’m not using absolute and relative positioning to deal with every element on the page, but I do use them to arrange components within a “section” while maintaining a logical source order.

Absolute positioning has gained a bad reputation over the years because of the way it was used: draw “layers” in a WYSIWYG tool that positions everything on the screen in a pixel-precise manner, and then watch all the text overlap when the font size is increased. I’ve often heard that “you shouldn’t use absolute positioning in your CSS if you want it to be accessible.” This is the same as saying JavaScript can’t be used if you want it to be accessible. It’s not the technique or technology—it’s how it’s used that makes it accessible or inaccessible.

When you use absolute positioning responsibly and creatively, and use em-based units for your top: and left: values, you can really come up with some wonderful techniques for maintaining a logical source order that also maintains usability and aesthetics for visual users.

DW: What are best practices, in your opinion, for handling link text and the associated title attribute?

DF: My opinion continues to evolve on the issue. It’s a challenge for a number of reasons:

1. Reading the title attribute on a link is a verbosity setting for screen readers that generally isn’t on by /files/includes/default.css.
2. When the settings are changed for the screen reader to read the title attribute, in many cases it reads the title attribute instead of the link text.
3. The tooltips that show up when the mouse is hovered over a link with a title attribute are not exposed to a keyboard user when they tab to that same link.
4. Accessibility guidelines tell us that we need to ensure that all links make sense out of context, and we should ensure that links accurately describe their destination.

So, then, what do I do?

I write my first draft without markup, then take another pass to add markup. While doing so I’m always asking myself if I could make both plain text and linked text clearer. Then, if I’m adding a title attribute to a link that is part of a sentence, I will revise my sentence structure so that the sentence makes sense if the link text is read, or if the title attribute is read in its place.

For example:

First pass

There are currently two popular methods to get a free iPod—you can either sell your soul, or win one.

Second pass (URLs omitted)

There are currently two popular methods to get a free iPod—you can either <a href="/">sell your soul like Jeff Croft</a> or <a href="/">win one of Mike Davidson’s contests</a>.

Final pass (note the title attributes)

There are currently two popular methods to get a free iPod—you can either <a title="see how Jeff Croft got his free iPod through a multilevel marketing type referral network" href="/">sell your soul like Jeff Croft</a> or <a title="participate in one of Mike Davidson's monthly iPod Shuffle giveaways" href="/">win one of Mike Davidson’s contests</a>.

In the final version, both link phrases identify the link reasonably well for the audience. The title attributes provide more detailed information, and the title attribute text reads well in place of the link text itself.

It depends on context—those two examples are links that are part of a sentence. Navigation and other links would be handled differently.

However, I’ve encountered a few things during recent user testing that I wouldn’t have believed if I hadn’t seen it with my own eyes. I saw a page full of links that were nothing but links to PDFs and DOCs (so, /files/includes/10.css links that said nothing but “PDF” and /files/includes/10.css that said nothing but “DOC”). In user testing, it performed brilliantly. I saw another page where links were perfectly distinguishable from one another, but performed horribly. Both of these go against conventional wisdom. I’m hoping to share more about that experience soon.

DW: It’s time for the Lightning Round! Skip navigation or skip to content?

DF: Skip to content, if at all. It tells you where you’re going, not what you’re about to skip.

DW: Can you make a living solely as an accessibility consultant?

DF: If you do your homework… and put it on your business card. The real question is: Would you want to?

DW: Priority 3?

DF: I do some of it anyway—it’s very little extra work for reasonable gains.

DW: :hover and pampering IE (to quote Tommy Olsson)?

DF: If it enhances usability, do it for everyone. If it doesn’t, why did you do it in the first place?

DW: Accessibility blog that people should spend more time visiting (aside from your own)?

DF: Find blogs of people with disabilities and start reading them.

DW: Going to bed early at SXSW?

DF: Worst. Idea. Ever.

DW: Six most irritating well-intentioned accessibility errors you see designers making?

DF: Tabindex. Tabindex. Tabindex. Onkeypress. Onkeypress. Onkeypress.

DW: You have three Web sites: boxofchocolates.ca, furtherahead.com, and simplyaccessible. What is the purpose of each of these sites?

DF: Boxofchocolates.ca is my blog. It gives me a place to write articles, share ideas, and participate in the Web standards community. I recently wrote an article at WaSP called Taking Aim at Target(.com) as well as a follow-up article the next day, after Target made some changes to address an accessibility problem on their Web site. Both were cross-posted at my blog as a means to collect comments.

Simplyaccessible.org is a micro-site with coding examples from my presentation at Web Essentials. I may be adding more examples of the same type over the course of this year: techniques using JavaScript, HTML and CSS to tackle accessibility issues in a simple way.

Furtherahead.com is my company site. I’m currently updating the site (yes, I know—who isn’t doing that?) to have it more accurately reflect recent changes and new directions my business will be taking. I have a rockin’ designer working on it with me. With any luck, I may even think of some ultra-super-top-secret content.

DW: Ultra-super-top-secret? A telltale sign that you are a giant in the industry!

DF: Nah, I’m only 5’8” and a svelte less-than-200 pounds. I had a fourth site, but I’m moving all my articles from that site to boxofchocolates.ca and furtherahead.com. Three sites are more than enough.

DW: As a member of the Web Standards Project, you are on two task forces: DOM Scripting and Accessibility (Assistive Devices). What is your biggest challenge, other than staying awake during long, boring meetings?

DF: No, no—you’ve got it all wrong. My goal is to sleep during the long, boring meetings. Errm, to be honest, we don’t have short or long meetings. Most of our work is done virtually.

My biggest challenge is to help make Web 2.0 applications more accessible. Because these applications are so new, there hasn’t been enough research into how they cooperate (or don’t) with assistive technology, nor has there been extensive testing with users to test out how some of the latest advancements behave. I hope in the short run to provide some (oh, I can’t believe I’m about to say this…) “interim techniques” that help current applications be more accessible while we’re waiting for assistive technology, browsers and development techniques to catch up with each other.

DW: Each January, you make a list of goals for the coming year, in three categories: coding, personal, and design/business. Care to share a few goals for 2006?

DF: Coding: Effective January 1, 2006 I’m going retro—back to <font>, <marquee> and inline JavaScript. And I’m going back to spaghetti code in all my back-end programming work. MVC frameworks and object-oriented design are sooooo 2005.

Personal: On a more serious note, I want to do four or five triathlons in 2006, continue to get in better shape, and write more. I said these last year, too, but I still want to do them for 2006. I want to read fiction or something other than business or Web-related books, be able to teach a Web development class in French, and (greatly) improve my drawing skills. I want to be more in tune with my roots as a teacher, so I’m hoping to teach more classes and workshops. I also want to be able to spend more magic time with my wonderful wife Kathryn and children Kaitlyn, Kyla and Kampbell.

Business: Most of us go to great lengths to schedule projects around each other. What happens? Those schedules get rearranged so that they all end up finishing at or near the same time. I’d like to see what happens if we schedule them all to finish at the same time in the first place. It might actually spread the projects out properly and let all of us get more rest.

DW: A seamless blend of magical thinking and project management. I like it!

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Accessibility, Web Standards