Designers have always had a vital interest in affordance, a term Donald Norman made famous in The Design of Everyday Things and later brought to the user interface design community in Alan Cooper’s About Face.
Article Continues Below
Affordance allows us to look at something and intuitively understand how to interact with it. For example, when we see a small button next to a door, we know we should push it with a finger. Convention tells us it will make a sound, notifying the homeowner that someone is at the door. This concept transfers to the virtual environment: when we see a 3D-shaped button on a web page, we understand that we are supposed to “push” it with a mouse-click.
Affordance only gets you halfway there#section2
A problem arises when someone easily understands how to use an object, but cannot execute the action required to do so. Most people who use wheelchairs understand how stairs are used, but affordance cannot help them climb a staircase.
In contrast, wide, automatic doors in grocery stores can be understood and used by people with and without special access needs. We call this combination of affordance and all-embracing accessibility “universal design.” In universal design, perceived affordance—that is, the implicit understanding of how to interact with an object—actually coincides with the user’s ability to execute the action. Universal design is, therefore, inherently accessible.
Some designers feel that universal design limits their creativity. To be universal, they argue, the design must be approached from the “neediest-user” perspective. To design a phone handset inteded for both senior citizens and younger customers, we must design for the senior citizens’ needs first: large number pads, large display, etc. And if we do that, younger customers, who expect “trendier” design, may not purchase the phone. This design approach results in a product that works for only one target group—we’ve achieved accessible design, but not universal design. And while accessible design is important, it doesn’t reach everyone in the same way, so we should logically strive for universal design whenever possible, and concentrate on accessible design only when necessary.
The accessible design dilemma#section3
What does this distinction mean in web design, where “universal design” and “accessible design” are often considered synonymous? Consider that accessible design elements include video captions and text transcriptions of audio files, implemented as necessary alternatives to the original content. Structural markup, on the other hand, is a powerful universal design technique. Organizing content logically using meaningful headings such as h1 and h2 creates affordance, because readers habitually scan headings before reading the text. A designer can create distinct heading styles, but the individual user is the one who ultimately accepts or rejects the designer’s ideas. Users can disable images and turn off or replace styles on the fly.
Still, for many designers, the unpredictability of interaction produced by universal design can be troubling. Sentiments such as “I have no idea how a screen reader works” demonstrate that as a design community, we still do not fully understand what accessibility—or universality—actually means. To progress, we must change the way we approach this task.
Accessibility is commonly touted via some text and a small hyperlink that leads to Section 508 at the bottom of a web page, a practice which upholds the spirit of the law. It usually reads something like this: “We are committed to making our site accessible and continue to test and modify the site for accessibility. Please do not hesitate to contact us if you have any problems accessing any of our content.” Some quick accessibility checks reveal that many site owners and developers consider the second part of that statement a convenient “get out of jail free” card.
Developers sometimes think that using standards-based development principles, separating presentation and behavior via external CSS and DOM-based scripting techniques, and applying alt attributes to images creates Section 508 compliance. They don’t want to spend more effort on accessibility until they get feedback from users who have problems with the site. The logic seems justified: good business practices prioritize requirements based on project constraints and ROI expectations. But while good coding practices help achieve accessibility, they must be applied with the right intentions to be effective.
Take the alt attribute, for example. Any decent HTML editor or validation tool will point out missing alt text, and most developers will provide a value for it, either to get the code to validate or to achieve accessibility. Valid code, however, does not equal accessible content. The W3C HTML5 Specification (Working Draft) explicitly recognizes this and provides detailed examples for alt text depending on the function and context of the image. You might argue that most web developers understand this distinction, but many websites show that this is not the case.
Accessibility: last on the list#section5
Just recently, a post on a popular web development forum caught my attention. It was titled “using ‘alt’ versus ‘title’ in an tag. ‘alt’ not work for Firefox 3.” Some replies, such as the following one, surprised me, and not because of the wacky grammar:
Alt attributes are required to validate, but unless it is some sort of gov’t website they are not required to use alt tags unless the information is vital and the equal information act, or whatever that act is called.
In my response on the forum, I pointed out the class action lawsuit between the National Federation of the Blind (NFB) and Target. To settle, Target paid a lot of money and agreed to intensive and expensive accessibility training for their web developers.
If a Fortune 500 company can’t get accessibility right, we can only imagine how difficult it may seem for smaller companies to achieve accessibility. Accessibility is often assigned a low priority for the following reasons:
- We would like to create accessible content, but we only have a small team.
- Nobody ever really complains about inaccessibility, anyway.
- Accessible sites are less aesthetically pleasing and they limit our design options.
- We really don’t know what it takes to make our website/web application accessible.
- Our target user group doesn’t include users with disabilities.
Of all the arguments, number four is really the only valid reason why a website or web application should have accessibility issues. You can resolve this issue—provide your web designers and developers with some minimal and gradual accessibility training, and keep the discussion alive. As for the rest…they merely require a small, but powerful shift in mindset
De-marginalizing accessibility with the inclusion principle#section6
Let’s explore the inclusion principle, which allows us to forget about the dichotomy between “them” and “us” so deeply ingrained in our social interactions. A focus on inclusion frees the accessible/universal design discussion from the conflicting interests described above and lets us embrace a broader, more organic philosophy. Above all, focusing on inclusion helps us understand that we do not only consider accessibility for others, but for our own good.
Consider this definition from the Institute for Inclusion:
Inclusive behaviors are those practices and behaviors that leverage and honor the uniqueness of people’s different talents, beliefs, and ways of living. […] When one is defined by the concept of a group, people can be limited by their knowledge or beliefs about that particular group. Instead,
inclusion embraces similarities and differences at the individual and group
levels for the attainment of the common endeavor.
The Institute also discusses inclusion as:
[r]ecognizing and supporting the intrinsic value of all human beings by creating and sustaining conditions that foster equity, empowerment,
awareness and competence at the personal, group and organizational levels.
Once we embrace inclusiveness, it becomes difficult to marginalize others as members of one specific group, such as “users with disabilities.” If we discard “us” and “them” thinking, we stop looking for reasons to avoid accessibility, and we begin to see others’ needs as our own. With inclusion, we don’t dismiss web accessibility requirements, we see them as a chance to create empowerment by embracing our similarities and differences.
Real-world inclusiveness#section7
This might seem like an unneccessary, theoretical dissection of accessibility, and you might say that a focus on inclusiveness doesn’t immediately solve your daily web design problems. But remember: We can embrace similarities by focusing on universal design and embrace differences by applying accessible design. Some “universal” techniques and elements include:
When we apply these techniques universally, they become “second nature” and a part of the mental model we use to build websites. Eventually, we don’t think of them as accessibility techniques, we see them as innate, universal web techniques. We experience a paradigm shift to inclusive design.
This can take a burden off both the client’s and the developer’s shoulders, because the remaining accessibility tasks are now better isolated. This facilitates an honest discussion about what it takes to achieve full accessibility, and developers can provide a more objective estimate for additional accessibility efforts.
While accessible and universal design are predominantly outcome-oriented, the new inclusive design model is distinctively process-oriented. It is crucial that the designer can identify with the accessibility requirements of a project. Where this is not the case, there is no enthusiasm, and without enthusiasm we are back at our old ways—marginalizing accessibility tasks.
Let’s get productive #section8
To see the inclusion principle in practice, let’s apply it to that list of objections to accessibility:
1. We would like to create accessible content, but we only have a small team. It doesn’t take much to get on the road to accessibility. WebAIM.org provides a really nice quick reference guide to help you get started. If you already know the basics, share accessibility knowledge among the team. For example, when you hear other developers discussing Ajax, send them information about accessible Ajax. If you use non-HTML formats such as Word or PDF, share checklists and how they can make a difference. (The U.S. Department of Health and Human Services is a good resource.)
2. Nobody ever really complains about inaccessibility, anyway. People do complain—just not to your face. When was the last time you were annoyed with a poorly designed product, but didn’t write a letter to the manufacturer? If your website has accessibility issues, the complaint is implicit in the design. Take this as an opportunity to be an advocate for change.
3. Accessible sites are less aesthetically pleasing and they limit our design options. I beg to differ: Nick Day, winner of the UK-based Accessibility in Focus award, got it right with his website English in Chester. Look around and learn from others. That’s what the web was designed for.
4. We really don’t know what it takes to make our website/web application accessible. Accessibility can seem overwhelming for a complex website or rich internet application (RIA). When you have a complex, multimedia-rich application, get creative. Find a school nearby for students who are blind or deaf, and ask for a volunteer to show you how they interact with computers. Investigate alternative ways of getting video captioned, such as dotSUB.
5. Our target user group doesn’t include users with disabilities. If that’s the case, then concentrate on your target group. Are you in the target group? Think about it: you are always a stakeholder in your projects. So, take your needs seriously and add value for yourself. How would you approach that?
How can you get started with the inclusion principle? Imagine starting your adventure with a black screen as in 2001: A Space Odyssey. Imagine your website. Now, take it a step further and imagine listening to your website rather than looking at it. This will help you to stop treating your website like a book. We sometimes forget that the web is a colloquial medium, and its narrative is not inseparable from its form.
What does your website sound like? Turn off your style sheet and look at what you’ve got. Suddenly the person listening to a website with a screen reader is no longer different from you—your needs are the same. Achieving the highest level of accessibility makes a lot of sense and should be part of your design efforts for reasons you no longer need others to justify for you. Embrace the inclusion principle and you’ll be the one who makes the case for accessibility.
