Posts Tagged ‘accessibility’
Accessible Interface Design, Part 2
Tips and Techniques for Accessible Web Applications
Alt &Title Tags. Always Use Them.
Alt &Title attributes are key tools for creating more accessible web applications. We can use them to label icons or other form controls to make them understandable by disabled users.
Use both the alt and title attributes as some browsers will show one but not the other. Make your text as descriptive as possible; don’t use ‘Delete’ instead use ‘Delete <filename>’.
Don’t put links in your labels as they could make it impossible for a user to click the label text for a control to activate it. Instead use an icon to launch an accessible pop-up window or other inline help text system.
All Form Controls Need Labels
Every form control, except buttons, needs label tags. This is how you would mark up a label for a First Name field in a contact form: <label for=”firstName”>First Name</label> <input id=”firstName” type=”input” />. This way a user can click the label text to activate the control. This is very important for check boxes and radio buttons because users with mobility impairments can have a hard time clicking these small controls. One tip you can use to make sure your developers have coded your labels properly is to click them. If the code has been done correctly, the control that the label belongs to should become active. I often use this technique when performing testing on sites I am working on.
Include Required Indicators and Help Text in Your Label Tags
By doing this you ensure that a screen reader user knows which fields are mandatory.
If you provide help text about how to fill in a field, place this text in the label tag too so that the screen reader users will be aware of it.
Also make sure that if you note that * denotes a required field place it at the top of your forms not the bottom. Screen readers, and everyone else for that matter, need to have a chance to be aware of it first.
Title Tags
All title tags, for example <title>Sign in to Spokentext</title>, should be unique for each page. This information is used by screen reader users to determine which page they are on and get context. It is also a good idea to do this for search engine optimization reasons and general usability reasons as your title tags become the text used for bookmarking a page.
Avoid Using Fixed Fonts
Internet Explorer will not allow users to scale the fonts on your site if you define your fonts in pixel values. Always define them in percentage (%) or (em). Both definitions allow your users to scale the font on your applications.
Plain Language
Of all the tips in this article, this has been the hardest one for me to convince my clients to do. Most of them think that the language they speak and write in is simple, plain language. But it is not. I have worked on projects where we have writers who are experts in plain language write our content just to have the client change it at the last minute, adding back in all of the industry specific language (in my case government language). And thus making the site harder to use.
A lot of my clients also take it personally when you comment about their content. They feel it is their job to write the content when it is usually their job to make sure the message in the content is correct.
All that said, plain language writing is critically important for the cognitively impaired and persons with low literacy skills. Do your best to make sure the text in your application is written in plain language no matter who’s ego you have to step on or stroke.
Document Structure - Semantic Code and Validation
For example, use <h1> Welcome </h1> not <strong> Welcome </strong> for headings. This seems so simple but people still don’t do it. If an interface uses headings correctly screen reader users can then navigate by heading thereby greatly speeding up their interaction with your site.
There is more to this than just headings. Use tables only for tabular data and if a section of content is a list then use list markup to display it. All of this helps assistive technologies provide context to the information within your pages. For example, JAWS will say things like “list of 10 items” or “table with 4 rows and 3 columns”. Both help users to create mental models of how your site works and what a page contains.
Overall, validation is important as proper code is easier to parse and interpret for assistive technologies.
Progressive Enhancement, AJAX and Hijax
Progressive enhancement is one of the best concepts to come out in a long time. We build our interfaces to work at a core level for everyone and then layer on other features for users who can take advantage of them.
As an example, in SpokenText I needed a way to inform members as to the status of their recordings. I created a page called “View Recordings” which listed all of the user’s recordings and had a Status column that let the user know at what stage in the process was the recording. To update the status of the recording the user could click the “Update Status” button. The page would then reload and the status would update. This is a simple, accessible solution, but not ideal for users without disabilities who could see content change automatically on a page. What I did was to write a small piece of AJAX code to automatically update just the rows which have changed without the user having to click any buttons thus improving the site’s experience without hurting the experience of users to whom this feature would be of no use.
We have to remember that we need to include disable people’s needs in our design but at the same time we don’t want to make our non-disabled users experience less than optimal. This is the design challenge that makes good accessible design so much fun to work on as an Interaction designer.
No JavaScript onChange Events
The issue with using a JavaScript onChange event to trigger an action is that a person trying to use your interface with a keyboard can’t move up and down the list of items in a select list. Once they hit the down arrow the onChange event executes and they are moved to a new page or whatever is scripted to the event.
Don’t Reload/Refresh/Redirect Pages Automatically
The issue with reloading or redirecting users automatically revolves around control and choice. It can take some users longer then others to understand what to do on a page and take action. If the page does not allow them to determine what to do next they will have lost all control over their interaction with the site.
Hidden Labels
Sometimes you need to create grids of fields. Like the following.
This is a good place to use hidden <label> tags. The <label> for A would be <label for=”a”>Calls Per Day from 9am to 5pm</label> and the label for B would be <label for=”b”>Minutes Per Call from 9am to 5pm</label>. The rest of the labels would just follow this pattern.
Here is the CSS code to hide the labels:
/* Hide labels when there is no room to display them */
.hideLabels {
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
Meaningful Link Text
Different user agents (like JAWS) allow users to view a list of links on a page. If you have ten links called ‘edit’ or ‘more’ the user would have no idea which link will perform which action.
For this reason use descriptive link text, or in some cases you can use hidden link text, to add the extra information you need to make the link meaningful while hiding this extra text from users who don’t need it. Hiding link text should be a last resort. Whenever possible avoid it as you never know how well it will work with all of the different accessible technology available today.
Hidden Link Text
Sometimes you want to use links within a list of data for users to click on. But the issue is that you will have the same link text repeated many times throughout the page. This breaks the rule about links being meaningful when taken out of context. To solve this we can use hidden link text which is only read by screen readers.
Here is the CSS code to hide the extra text:
/* Hide link text */
span.hideSpan{
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
Using Icons for Actions
This is a very common approach I use to solve the problem of deleting items in a list. By using an image I can give it a very meaningful title and alt text . In the example below, the alt and title attributes for the delete icon will be “Delete Benjamin Graham The Intelligent Investor”. This way a screen reader user knows exactly what will happen when they click this icon. Make your icons as large as possible, at least 16px by 16px or bigger. And, if you can, extend the hit area for your icons using CSS.
Don’t Use Access Keys
Access keys were an interesting idea. But the issue is that access keys can conflict with the shortcut keys used by a user’s adaptive technology. For users of tools like Jaws, their whole interaction with a computer is driven by utilizing Jaws shortcut keys. In your design, you might think that you are doing disabled people a favour by putting access keys into your web application but in the end you might be making their experience worse.
Don’t Modify the Natural Tab Flow
By using tabindex=”x” you can control the order of how users will be moved from field to field on your page. The issue with this is that, to a user of a screen reader, this can make it hard for them to form a mental model of the whole form on the page and how one field relates to another. A well designed form should have a default tab order that makes sense to all users. So don’t use tabindex to specify the taborder as you could be potentially making your site harder to use by disabled people. This can also make future maintenance harder if you want to add a new field in a page because you will need to update all of the existing controls tab indexes. A very tedious and error prone task. I have seen applications where the tab order is all over the place because someone thought it would be a good idea to add tab indexes to each control.
Keep Legends Short
When a screen reader user using JAWS, for example, is in “forms mode” all legends are read to him or her before the label text for a form input is read. So you can imagine how frustrating it would be to have to listen to a long sentence as you try to figure out which item you wanted to select in a radio group. Keep fieldsets to under six words to avoid this.
This example comes from an administration interface I worked on. It is nice and short. Using a screen reader is a slow way to interact with a computer. We have to make sure we do our part to use as little text as possible so that we do not waste screen reader users’ time.
Deleting Items From a List
Check boxes are small targets to click so we need to make sure that we always have labels for them. The user can click the label to activate the check box.
Below is a screen shot from SpokenText.net where I used the recording name as the label for each check box. This way the user can figure out which check box relates to which row in the table. This is a very common pattern but it is surprising how many times people don’t follow it. If I needed more information to make the label clearer I would think about using some hidden text within the label tag.
Avoid Using Multi-Column Layouts for Forms
Forms which are laid out horizontally can be hard to use by people with screen magnifiers since they might never scroll right to see the second part of the form. Most forms are laid out in one column or two columns with the fields in one column and the form controls in the other. Both of these two options work best for screen magnifier users.
Error Messaging
Whenever possible use large error boxes that stick out from surrounding content and offer good contrast. They should be at the top of forms so that a screen reader user is able to read them before traveling to the field which needs attention.
Simple and Elegant Design is Best
Keeping it simple is very easy to say but is hard to do with all of the issues we face when designing applications. From clients to marketing departments everyone is trying to cram their features or opinions into an application’s design.
But it still holds true, for me, that the simpler an application is to understand it will be generally more accessible if the basic rules regarding accessibility have been followed.
So strive to keep it simple and to borrow a phrase from a great book “Don’t make users have to think”
The Future of Accessible Web Applications
Accessible Rich Internet Applications (ARIA ) looks very promising. With it we will gain concepts like roles and live regions, some of which are in Firefox now. Firefox’s implementation of ARIA allows desktop-style widgets such as tree views, menu bars and spreadsheets. These are accessible both with the keyboard and assistive technologies such as screen readers, screen magnifiers and alternative input devices. It also helps provide accessibility solutions for AJAX-style live updates to regions on a page. Few access technologies support ARIA at the moment but will in time.
AxsAJAX, Google’s foray into this area is also interesting. You can check it out at http://code.google.com/p/google-axsjax/
Operating Systems and Accessibility
At the moment the Windows platform is still the most accessible operating system when you use it along with specialized access technology for the disabled. Out of the box, Apple’s OS X is the best. Mac includes a superb screen magnifier and screen reader which are great for free but not as good as the software you can buy for Windows. I have played with Linux’s accessibility and it is coming along but is still years behind Windows and OS X.
Development Platforms
As you might guess from the previous section, Windows development platforms are still the best for creating accessible desktop and thick clients. You can make Java applications accessible but users of tools like JAWS will have to install extra software to get your application to work for them.
I mention this because if you have the ability to pick which tools you use to develop your software you might want to consider using a development platform which is accessible to the largest number of people possible.
Conclusion
It is true that well designed, properly coded, visually appealing applications can be even more accessible when they use proper structure, plain language, headings and label interface controls in a meaningful way. I challenge everyone reading this article to make your next application beautiful, usable and accessible.
On Web Accessibility
At one point in our pre-child lives, my husband and I had very similar cars. He drove a maroon Acura Integra with a sunroof and all sorts of toys. Being in grad school, I had a more stripped-down model that was screaming, comes-with-3-free-speeding-tickets, red. The first time my brother saw my car, it was parked next to my husband’s car. He couldn’t tell them apart-until my husband pointed out the lack of a sunroof, and so on… My brother has a type of color deficiency that prevents him from seeing differing shades of similar colors.
Why am I telling you this and what does it have to do with web accessibility? Because websites that vary only the shade of text to indicate levels of importance don’t work for someone like my brother. Going from maroon to red without actually changing the weight or some other feature of the typeface can be meaningless to a color deficient person. WebAIM estimates that up to 20% of web users have some form of disability. Would it be wise to ignore 5 or even 10% of your potential customers?
Why Accessibility?
When people hear “accessibility”, they often think along the lines of people using assistive devices, such as screen readers for the vision impaired. But web accessibility is so much more. It is the appropriate use of colors for the color deficient, appropriate spacing on menus for those with fine motor skills, and layout design to allow for assistive devices. The World Wide Web Consortium (W3C) has a good article on disabilities and has put together scenarios showing how different disabilities can affect a user’s experience. The growth of information, and importantly the ability to interact with others, on the Web has opened new doors and experiences for many who are homebound or otherwise unable to get out.
Social Networking is a prime example of a Web 2.0 application that can really benefit the disabled community. Yet, AbilityNet’s recent State of the eNation Report on the topic shows that social networking sites, such as MySpace and Facebook, are unfriendly to the disabled. The primary culprit is the visual-only CAPTCHA tools in place. While they may prevent spam, they also prevent most users with visual impairments, dyslexia, or learning disabilities from even registering. Once registered, even more problems exist. The report is a very interesting read, for those interested, at http://www.abilitynet.org.uk/enation85.
The idea of accessibility is larger than just the user experience, though. There are many United States regulations mandating accessibility for websites used by government entities. In 1998, Section 508 of the Rehabilitation Act was amended to mandate that the federal government grant access to those with disabilities that is comparable to the access granted to the non-disabled population. In a nutshell, all websites developed for use by the US Government or any of its entities must meet accessibility guidelines. Many states and other countries have also developed similar laws and regulations. We recently completed a website for a college part of the state university system. The number one requirement was that it be accessible.
Making Sites Accessible
Making a website accessible does not mean it has to be black text on a white background using default typefaces. From a graphical and layout perspective, AccessSites.org provides links to accessible sites that are neither boring nor bland. Examples include Seattle-based coffee.net and UK-based InRetirement Services.
Making websites accessible means you consider your audience-are they aging, likely to have disabilities of any kind. It means that you use common sense coding techniques. W3C gives us 10 quick tips to help create accessible websites.
- Images & animations: Use the alt attribute to describe the function of each visual.
- Image maps. Use the client-side map and text for hotspots.
- Multimedia. Provide captioning and transcripts of audio, and descriptions of video.
- Hypertext links. Use text that makes sense when read out of context. For example, avoid “click here.”
- Page organization. Use headings, lists, and consistent structure. Use CSS for layout and style where possible.
- Graphs & charts. Summarize or use the longdesc attribute.
- Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
- Frames. Use the noframes element and meaningful titles.
- Tables. Make line-by-line reading sensible. Summarize.
- Check your work. Validate. Use tools, checklist, and guidelines at http://www.w3.org/TR/WCAG
© W3C (MIT, INRIA, Keio) 2001/01 (source: http://www.w3.org/WAI/quicktips/)
The Web Content Accessibility Guide 2.0 at http://www.w3.org/WAI/intro/wcag.php provides some good information on the guidelines and more detail on how to achieve them.
Making your site accessible also means you validate your code. For a long time, Bobby from CAST was the standard. In 2004, it was acquired by Watchfire Systems and then sold to IBM in 2007, which has incorporated it into their Rational Policy Tester Accessibility Edition. There are still a number of free and low-cost tools available to developers. A fairly comprehensive list can be found at W3C (http://www.w3.org/WAI/ER/tools/complete). My personal favorite, though, is WAVE from WebAIM. It provides a nice visual interface, showing where problems may lie and how your website flows in a text-only browser. It also provides a Firefox tool bar, letting you evaluate pages as you access them.
Finally, there is a little known side benefit to accessible websites-search engine optimization. Search engines are essentially the lowest common denominator. They don’t care about the visuals, only about the content and how it flows. Sound familiar? Accessible design focuses on the content and delivering that content to the user-and that’s what a website should be all about anyway.
Accessible Interface Design, Part 1
Accessible Does Not Mean Boring
It is amazing to me how many people think that accessible design means boring, dull interface design. Nowhere in the Web Content Accessibility Guidelines (WCAG) guidelines from the W3C do they say please make your sites ugly and boring. They just say make them accessible. But most designers and developers take the easy way out and dumb everything down to a point where their applications are hard to use by everyone.
As an Interaction Designer (ID) it is interesting to think about how the interaction for your application would work if you could only hear it. Or had limited mobility and had a hard time clicking small icons.
It is possible to make an interface which is technically accessible but is not usable or is hard to use by disabled people. The analogy I use is that a blind person can open the door to the house but once he gets in the furniture is laid out in a strange way and when he touches the sofa, the coffee table magically appears. From an Interaction Designer point of view I want to make every interaction I design usable by the highest number of people possible and hope you will do the same.
A lot of what I will cover in this article is just plain good design with a few tweaks to make it more accessible. Overall, I like to keep it simple and clean.
Resources
On the W3C web site you can read about the W3C Web Content Accessibility Guidelines. I suggest that you do. They are not all that easy to understand and might put you to sleep but it’s still a good idea to have read them at least once. Don’t worry if you don’t understand all of them; most people don’t the first time they read them.
I think the major reason why most people find them hard to understand is that they don’t explain why you should, for example, make all links meaningful when taken out of context. This is actually because some user agents allow users to navigate a list of links, so a bunch of ‘click here’ links will not be of much help to your users. Hopefully this article will help with that.
Accessible Rich Internet Applications (ARIA)
http://www.w3.org/TR/wai-aria-roadmap/
http://developer.mozilla.org/En/Accessible_DHTML
http://alistapart.com/articles/waiaria
Hijax
http://domscripting.com/blog/display/41
Web Aim
www.webaim.org
SpokenText
www.spokentext.net
Why Accessibility
There is a lot written about this so I will just cover it briefly and provide some links at the end of the article for further reading. Basically, it is the law in most of the developed countries and is just simply good for business. It is also a lot of fun from an Interaction Designer’s point of view.
There is a term in the disabled community which I find funny; certain people with disabilities call non-disabled people TABs or the Temporarily Able Bodied. It is just a matter of time before we all get a disability of one kind or another. Especially as sixty to eighty percent of people suffer from hearing loss and/or vision loss as seniors.
Many Different Disabilities
There are many different disabled groups, not just the blind. Here is a short list of some of the groups we need to design for:
- Visual
- Blind
- Low vision
- Auditory
- Deaf
- Hearing impaired
- Motor
- Cognitive
- Learning disabled (80 percent of all disabled)
- Mental disabilities
- Seizure
- Print Disabled
- Visually impaired
- Learning disabled
- Illiterate (20% of Canadians)
- ESL
A great place to learn more about all of the disabled groups is on the Web AIM site at http://webaim.org/articles/
It is very interesting how a solution like keyboard access can benefit many different groups like the blind and mobility impaired. Or how using headings, white space and logical chunking of information can help both the blind and the cognitively impaired. Blind people can use properly marked up HTML with headings to navigate using shortcut keys, and the headings also help the cognitively impaired visually parse and understand the page and its contents.
I challenge you to try and get into the head space of someone who is blind or learning disabled and evaluate your next application. It is a very interesting and rewarding experience. After you have created your mock-ups, test them with disabled people just as you would with non-disabled people.
Many Different Adaptive Technologies
We have to keep the variety of adaptive technologies in mind because by trying to improve one disabled person’s experience, we might hurt someone else’s experience. Some people think that the only people we need to be concerned about is the blind. This is definitely not the case.
- Blind (Screen Readers)
- JAWS, HAL, Window Eyes
- Visually Impaired (screen sagnifiers)
- ZoomText, Magic, Lunar
- Mobility Impaired
- Dragon Naturally Speaking (speech recognition)
- On screen keyboards
- Puff and blow systems
- Eye tracking systems
- Wet ware system (embedded in brain)
- Joy stick systems (on wheel chair)
- Mouth stick (tap keyboard)
Interesting Tidbits
Here are just a few technologies that were first created for the disabled but have gone mainstream:
- Voice recognition (car navigation systems)
- Word prediction (cell phones)
- Text to speech (phone systems)
- Closed captioning (at the gym)
Created for the disabled but benefit everyone:
- Curb cut outs
- Automatic doors
- Ramps
- Elevator floor indicators
- These were created for people in wheel chairs. Can you imagine not having them now?
Part 2: Tips and Techniques for Accessible Web Applications
In Part 2, scheduled to launch in November, I’ll cover tips and techniques for Web applications as it pertains to the accessible audience. Check back next month for Part 2, and don’t’ forget to leave a comment or a question today!
Already a member of Facebook and/or LinkedIn?
Join our group online and share the link!
