Derek Featherstone Interview
Got something to say?
Share your comments on this topic with other web professionals
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.
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.
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.
DW: What strategy do you use for designing or evaluating the accessibility of a page or feature?
DF: I start with these four questions:
- What information is presented?
- What is the expected interaction?
- How we do that semantically?
- 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> 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.
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.
When you use absolute positioning responsibly and creatively, and use em-based units for your
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
DF: My opinion continues to evolve on the issue. It’s a challenge for a number of reasons:
- Reading the
titleattribute on a link is a verbosity setting for screen readers that generally isn’t on by /files/includes/default.css.
- When the settings are changed for the screen reader to read the
titleattribute, in many cases it reads the
titleattribute instead of the link text.
- The tooltips that show up when the mouse is hovered over a link with a
titleattribute are not exposed to a keyboard user when they tab to that same link.
- 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.
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 href="/">win one of Mike Davidson’s contests
Final pass (note the
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 title="participate in one of Mike Davidson's monthly iPod Shuffle giveaways" href="/">win one of Mike Davidson’s contests
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.
: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.
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
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!
Got something to say?
Share your comments with other professionals (0 comments)
Related Topics: Accessibility, Web Standards
Derek Featherstone is a web developer, instructor, author, and web accessibility consultant based in Ottawa, Canada. When he’s not building web sites, blogging, or teaching others about web standards techniques, he can be found making mean “Smiling Jerry” drinks, and then (usually after drinking them) performing various bar tricks.
Carolyn Wood of pixelingo is a web designer, copywriter, content strategist, and the Editor in Chief of Digital Web Magazine. Her long list of loves includes the web, design, storytelling, and making lists. If you meet her, ask her to tell you the story about the midwife and the bank robber.