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.

Learn more about Mark McKay

Prior to the advent of Web 2.0 technologies, content creation for CMS-driven websites was typically managed by a few organizational users. The idea was that power in the hands of the few would make site creation and maintenance less cumbersome overall. However, with the evolution of website creation, the introduction of Web 2.0 tools has put content creation in the hands of the many causing an explosion of content which begs to be properly managed. This management creates various challenges for user experience specialists.

Problem

While CMS sites featuring Web 2.0 tools, such as Wikis and Blogs, allow users to upload and manage their own content, several potential issues can arise.

• Disjointed Content Pieces
• Poor Search Results and Findability
• Fitting Unlimited Content into a Limited Space

A user experience specialist can assist in avoiding these issues. Three important activities to encourage the success of the content managed system are:

• Creating strong guidelines through a style guide
• Using card sorting to create a strong site map and controlled vocabulary
• Flexible layout structures

Challenge: Disjointed Content Pieces

When multiple users manage and update a single website’s content, there is a risk the site’s content will become disjointed. Each user’s distinct writing style will impact the continuity of each page. When the home page or section landing pages contain various writing styles, readers may question the credibility of the site.

Users also often take advantage of the WYSIWYG editors, available in most content managed systems. These editors allow the user to specify formatting, such as text size, typeface, and justification. Without restrictions and guidelines on content format, the site’s look and feel can become disjointed, because it is easier for users to insert tags and other special items within an article than create HTML code.

Finally, ensuring the most recent version of a content piece is available to the end users can be a challenge. When an article is updated while a user is viewing it, the content he is reading at the moment could change when he refreshes the screen. At this point, the viewer could become confused and think he has been diverted to a different article. Alternately, the reader may finish reading the article, return to a list of items after the article’s content has changed, and not receive any visual cues that the article has been updated.

Solution: Create Strong Guidelines through a Style Guide

Differences in categorization techniques, increased risk of mislabeling, and the differences in formatting preferences of each user can lead to a distracting segmented-looking site that lacks solid information indexing. Style guides identify the formatting for the presentation of the information contained on the website. Some elements the style guide defines are:

• Header font, size, and color
• Text font, size, and color
• Formatting of links
• Displaying the timestamp for content pieces

Style guides can eliminate the appearance of disjointed content. Depending on the flexibility of the software used for the content managed system, the style guide can be incorporated into the site in the form of a CSS document. CSS stands for cascading style sheet. CSS documents help separate the content of a web page from the visual elements and allow the administrator to control the formatting of a page without touching the content. If the style guide defines showing the timestamp for when content was uploaded or last edited, site readers will benefit from knowing how recent or valid an article or photo is. Similarly, when users add content containing text to a site that utilizes a solid style guide or CSS file, the visual display to the end viewer will look the same as the other content within the site.

Challenge: Poor Search Results and Findability

Web 2.0 created a new concept called folksonomies. In folksonomies users are also responsible for attaching metadata to all content they have submitted, including articles, photos and videos. Online photo albums, such as Picasa and Flickr are a great example. When a user uploads a photo to either service, they have the additional capability to attach key words that describe that photo. User generated metadata adds value by creating a collaborative blend of different people’s thoughts. It allows for possible tags that might not have been thought of by the organization. However, a user may not always provide metadata or valid metadata, which can make information difficult to find and also challenge the strength of the controlled vocabulary.

Solution: Use Card Sorting to Create a Strong Site Map and Controlled Vocabulary

Card sorting is a usability technique that allows users to determine the best way for items to be grouped. In open card sorting, no pre-defined groups are given to the participants. Participants determine their own group definitions. In closed card sorting, participants place the items into pre-defined groups provided by either the business customer or the user experience specialist. Card sorting is most often used to help determine the navigation for a site and how users visiting the site should view the content.

Results of the card sorting exercise can then be used to inform the development of the site map and navigation approach. The key to this task will be not only creating the right number of main and secondary navigation items, but avoiding using terms that are ambiguous. Labeling must be done well, using terms that are easy for site visitors to comprehend and intuitive enough that there is not a question of what content is found in each category or section.

The difference between what a user searches for, what they actually want, and what metadata lies within the system can be drastic. Controlled vocabulary helps to bridge this gap by relating terms to one another so that the term a user enters can be linked to the metadata attached to the content piece. Giving users the ability to tag their own content is one of the more enticing features of Web 2.0 and content managed systems, but creates the risk of invalid metadata which can result in poor search results and findability. A folksonomy is not the same as a controlled vocabulary, and therefore cannot replace it. Similar to a thesaurus, a controlled vocabulary shows similar terms, either broader or narrower, that are related to the original term. A solid controlled vocabulary, using ideas generated from the card sorting activities will keep the search ability within the site operable.

Challenge: Unlimited Content vs. Limited Space

When any user has the ability to create and upload content, the amount of content contained in the site can be endless. This creates a challenge of determining where all this information should be placed in the front end so that those viewing the site will be able to find it, yet not be overwhelmed by a clutter of information. Site owners and the user experience specialist will need to determine the following:

• What types of information appear on landing pages and the home page?
• Do the most important or read items appear on a landing page or is it most recent?
• What is the limit of the number of articles or media that appear on a main page?
• How many links to archived pieces are shown in an archive list?

Solution: Flexible Layout Structures

A good solution to this challenge is to allow for flexible layout structures that define how many regions or pieces of content will be contained in a page, while allowing various types of content to be placed in that space. Define which sections are to be used for main content, which sections are to be used for supplementary content, which can be collapsed or moved and which need to remain stationary. Defining all the possible ways the space can be used but adhering to the organization of the various sections will create a good information space that is user friendly yet displays as much or as little as desired.

Final Thoughts

Content managed systems combined with the arrival of Web 2.0 create an incredible opportunity for collaborative content development. The expansion of knowledge it brings will enhance everyone’s lives; these sharing and social media environments will create widely distributed communities for sharing and growth. However, as with any good thing, it will also bring its share of challenges. These challenges will only spark new opportunities for improving the user experience.

Prior to Web 2.0, there were limited content authors, and it made it easy to disregard the multitude of users that visit a site every day. Web 2.0, in conjunction with Wikis and Blogs, have made user experience specialists think twice in regard to the stability of the sites they have created. Taking additional time to fine tune site maps, layout structures, and style guides will ensure the success of such sites in the future.

References

Boxes and Arrows: Card Sorting: A Definitive Guide.
Web Developer’s Virtual Library: Benefits of Cascading StyleSheets.
Wikipedia: Web 2.0.

Learn more about Tonia M. Bartz.

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.

1. Images & animations: Use the alt attribute to describe the function of each visual.
2. Image maps. Use the client-side map and text for hotspots.
3. Multimedia. Provide captioning and transcripts of audio, and descriptions of video.
4. Hypertext links. Use text that makes sense when read out of context. For example, avoid “click here.”
5. Page organization. Use headings, lists, and consistent structure. Use CSS for layout and style where possible.
6. Graphs & charts. Summarize or use the longdesc attribute.
7. Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
8. Frames. Use the noframes element and meaningful titles.
9. Tables. Make line-by-line reading sensible. Summarize.
10. 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.

Learn more about Beth Weise Moeller

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!

Learn more about Mark McKay

In our first two months, more than 1100 people have joined UXP through Facebook and LinkedIn. They are in  over 10 countries, work in a range of UX positions at large and small companies, as sole proprietors or as researchers and educators of user-centered design. Our members are specialists in the user experience. And their numbers are growing. We’re looking forward to hearing from many of you as we get this new professional group going. Join us and submit your articles and ideas. We want to hear from you!

UX Professionals is dedicated to reviewing and posting quarterly content for any UX discipline and we welcome the diversity of any subject matter that outlines both the conflict and resolution. If you’d like to contribute, please see our Contribute page for information.

We welcome your feedback and hope that if haven’t already registered that you take the time to join us and submit content for the site.

Sincerely,

UXP Staff

Polos versus Doc Martens. Peet’s versus Starbucks. Hat Heads versus Bed Heads. Every project and every office has multiple personality types. How you work with them and how you manage the rationale of decisions and feedback is crucial to your success.

By applying the right relationship management techniques, you can calm tension, communicate more easily, run your projects more efficiently—and you might get additional work since the relationship with the client will be strong from beginning to end.

Hat Heads and Bed Heads

It’s important to know what these two personas are and what they represent.

Hat Heads are everywhere: project managers, senior management, and many other people who may not intuitively understand the benefit of creative discussion. Whether they’re clients or team members, Hat Heads often see themselves as the champions of the greater good. They belong on the project—their roles are essential—but they’re not always as flexible as you’d like them to be, and you have to know how to communicate with them.

Bed Heads are those who believe in the lifestyle of a hard-working free thinker. They may get up and come into the office later than some and take an actual lunch hour to break up the daily routine, but may also work all hours of the night because they believe in what they’re doing and know they’re giving the best they have to offer. Bed Heads usually fill creative or marketing roles: they’re designers, developers, and art directors. They sometimes believe that Hat Heads are being difficult just because they can.

Even a two-person team has the potential to have these two personalities, as do couples and siblings. Like chocolate and peanut butter, their differences don’t mean they shouldn’t be together—you just have to mix them in the right fashion. Enter: relationship management.

Relationship management

A creative manager has to constantly and successfully manage relationships to nurture positive interactions between Hat Heads and Bed Heads and get the entire team performing under blissful, caffeinated conditions that encourage unfettered creativity. The creative manager (or project manager, depending on the team structure) is the protective liaison who makes sure that if a Hat Head and a Bed Head are in the same room, they realize they’re charging towards the same goal: recognized brilliance and an awesome launch party.

To accomplish this, we can use a set of standard project management techniques that focus on building and maintaining successful relationships, and that can be applied to both internal and external clients. These relationship management techniques can be used in three ways:

• at pre-client project meetings,
• on the fly, and
• at post-meeting assessments.

Pre-client meetings: groundwork for good relationships

Here’s a funny thing about being a creative or project manager: whether you’re working on an internal or external project, you typically know more about the state of the project than anyone else. Especially on large projects, where the rest of the team knows mainly rumor and hearsay.

To create team balance and cohesion, you must pull the entire team—including the sales person or account manager who landed the deal—into a room to run through an agenda that covers why the team members were selected and what their specific roles are as well as ground rules for communication with the client team and the project’s overall timeline. By getting the entire team in the room as soon as possible and including them in early decisions and direction, you create a level of ownership that will help you manage the team.

The daily show

Your next goal is to get your team (or teams) into a rhythm and set the expectation that their involvement is critical to the project’s success. If you get your team together for 10 to 15 minutes every day in a relaxed environment to share status and give the staff a chance to raise any issues, you offer the proper forum for things to surface before they get out of control. Keeping it as a roundtable will seem sometimes boring and mundane, but it puts people on the spot and makes them think about their work. And, if they don’t seem to have anything to offer, ask a couple of questions. It’s ok to coax them into a discussion.

By the way, if you’re not the one running the project, feel free to initiate this with your creative manager if one hasn’t already been set up. They’ll probably thank you for thinking of it since they’re probably thinking about a million other things.

On the fly: keeping relationships strong

I remember the first time a client showed high levels of frustration during my project. The vice president of sales and marketing for a now-defunct insurance company was screaming at our team for not applying the correct brand strategy (we’d used product-specific colors instead of the corporate color scheme).

Instead of getting into a battle with the VP, I lowered my pen to the table, waited until he’d finished, and very politely explained that the creative brief that bore his signature made it clear that we had used the correct color scheme. I explained that I understood wholeheartedly that things change (more than likely, to be fair, because of the opinions of a more senior-ranking member of the client team), offered to initiate a change in scope, and even told him that we’d do it for a lesser amount than our typical rate.

Rule #1: get everything in writing

What would have happened if I hadn’t gotten that section on the color scheme into the creative brief? How many times have you walked away thinking that you had everything in hand, only to discover later that you have no way to verify or validate a client’s approval?

Conflict can occur when one party assumes or tries to execute on a memory of a conversation. In addition to getting formal sign-off, you should always write down all comments, feedback, and thoughts during a conversation and send them to the necessary recipients in a follow-up e-mail in an effort to validate the information. The extra effort will help keep your Bed Heads and the client’s Hat Heads on the same page.

Rule #2: employ the buddy system

In almost every project or team environment I’m involved in, I make an effort to create a high level of trust with a strong team member right away, so that we can discuss situations and issues with a sense of confidence. It certainly doesn’t mean that what I’m saying to this person stays secret—I’d be a fool if I thought that were the case, especially in a client-vendor relationship—but if you can build a good relationship with a strong, supportive team member, that person can help you build the remainder of the team’s trust and support.

Rule #3: match the right hat to the right situation

You probably have more “hats,” in the sense of specific skillsets, on your project than you think you do. One of your responsibilities as creative manager is to take inventory and match the right hat to the right situation.

This matters not just in the initial distribution of responsibilities, which you may or may not control, but when you need the right hat to handle a potential relationship problem. There are invariably times when you find yourself in discussion with someone whose personality type or working style is quite different from your own, and you need to step back and think about which hat helps the situation.

Example: a client team member who has been harboring a deep dislike for the navigation layout your team has designed, but who has been uncomfortable speaking up in public, stops you in the hallway and brings up the topic. Your responsibility is to manage this relationship before it a) gets out of hand, or b) stops the momentum and natural flow of the project.

Consider the personality and working style of the person you’re speaking with, then take the time to explain things accordingly. Design is part science and part creative subjectivity, so select the right way to explain your team’s choice and take the time to lay out a valid argument using language your client can understand.

Rule #4: manage conflict

Okay, so you’re in a meeting and you’re discussing a design comp and the third person to your left is “that guy.” He’s been around the block. He knows this “design stuff,” and he wants to be heard. Unfortunately, he’s from the budget office and his only design experience was a poster he did for his cousin’s lemonade stand when they were nine. And a half.

Your responsibility is to keep it cool. Here are some well-known conflict management tips that you can use to keep the discussion going your way:

• Don’t interrupt—even if the person speaking is on your own team and you can stop them, don’t immediately try to keep them from having their say. You’ll have a chance to respond.
• Lead by example—as the creative or project manager, your responsibility is to lead and not let emotions get in the way, even when personality conflicts arise. Your client and your staff are watching you.
• Keep your language neutral—avoid using terms like “never” and “no.” Use inclusive terms: “I think we agree that our goal is x and I’d like to see us get there together.” It may sound corny, but this is an important part of effective communication.
• Compromise—I realize you can’t compromise on some terms (finance can be a hot topic), but when it comes to design elements and copy, don’t let pride end your lucrative project. A client isn’t always right, but they do usually pay your electric bill, so do your best to find a solution that lets you maintain your integrity and also meets the client’s needs.

Post-meeting self-assessment

Nobody is perfect, and that meeting you just left might have left you with a couple of chinks in the armor. No matter. Take a moment to breathe deeply and reflect on how the meeting or conference call went. Try the following questions as a partial self-assessment to help you get started:

• Did I achieve the intended goal of the meeting?
• Was there anything I needed to address, but didn’t?
• Who was not at the meeting that I should reach out to?
• What action items can I take out of this to be proactive?
• Is there anything I should change for the next meeting to make this relationship stronger?

What’s next?

The next time you go attend a client or team meeting, take a mental (or written) note of the personalities in the room. Think about how you would communicate with them if you had to present a new idea today. Would you be able to convince them that your idea is the right idea? On the individual and team levels, is their personality in line with yours, or do you need to adapt? And if you do, what does that mean?

Adaptation doesn’t just mean change. Adapting is more about being flexible and seeing other points of view. It’s impossible to change a person, but we can all adapt in so many ways:

• A client manager can adapt by reading the client’s body language and suggest alternatives without sounding like they’re backpedaling.
• A designer can adapt by willingly incorporating client feedback even though it goes against the theme of their initial artwork.
• A copywriter can adapt by loosening the strict guidelines surrounding corporate gobbledygook and allowing the piece to be more fun so that it becomes more of the brand.

Conflict management and conflict resolution are two wonderful starting points on your path to proper relationship management. If you are already a seasoned project manager, think of the personality side of the equation or take a moment to do a relationship-building self-assessment at the end of your day. If you’re a designer or developer, a copywriter, or an interactive dynamo, you can expand your relationships and strive to adapt your approach to suit the situation.

In the end, you have all the hats you need. Some may not look as good on you as others, but that shouldn’t matter. If you’re wearing the right hat, your client will appreciate the effort. Just don’t spend so much time choosing the right hat that you forget to wear pants.