Sign up to newsletter


    UX resources
    Home / Uncategorized / Accessible Interface Design, Part 1

    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.


    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)


    Web Aim


    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

    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

    Leave a Reply

    Your email address will not be published. Required fields are marked *