Twitter feed


Getting Started with Accessibility in Techcomms

Karen Mardahl, Technical Writer at G.R.A.S. Sound & Vibration, Denmark

Twitter: @kmdk Website:

“Where do I start?” This is one of the first questions I hear when discussing accessibility for technical communicators. I shared my suggestions in an Adobe eSeminar with Tom Aldous, the Adobe Technical Communication Suite Product Evangelist. This article is a collection of the links from the eSeminar.

Read this article with the definition of disability from the World Health Organization in mind (WHO).

[WHO] acknowledges that every human being can experience a decrement in health and thereby experience some degree of disability. Disability is not something that only happens to a minority of humanity. The ICF thus ‘mainstreams’ the experience of disability and recognises it as a universal human experience.
– from the International Classification of Functioning, Disability and Health (ICF)

If disability is a universal human experience, why aren’t we all thinking accessibility in all our communication?

Start with your writing

Content is at the root of all we do, so that is a logical place to implement accessibility immediately. All it takes is plain language. Unfamiliar with the concept? The links, including Nordic resources, will explain it.

The Design To Read site is a good place to understand the value of the words you choose.

Plain language resources are

The EU has produced an excellent little booklet called How to Write Clearly in 23 languages! You can download a free PDF of the booklet from the“How to Write Clearly” page in the EU bookshop. In case that link changes over time, just search for the EU bookshop on the page for EU translations and drafting resources.

While we’re on the topic of the EU resources, note these EU resources on accessibility.

Next Up is Alt Text

The next easy-to-start step is alt text, or alternate text. This is text that is used “in place of” an image. You can see this text when a large image is loading on a webpage. If you can’t see, your screen reader reads it for you. So simple, and yet so many forget or ignore this step in writing content. I won’t explain more because the WebAIM page on alt text says it all. Memorize it!

Steve Faulkner of The Paciello Group is working on HTML5: Techniques for providing useful text alternatives. It is a valuable companion to the WebAIM article.

Accessible PDFs

Making accessible PDFs is a natural extension of the PDF work many technical communicators already do. Download my presentation on techcomms and inclusion from the TCUK 2010 conference to read the slide notes explaining this process. The notes include more useful references.

Captions and Transcripts

That presentation I just mentioned also contains information about adding captions and doing transcripts.

I cannot emphasize enough how important captions or transcripts are for truly including all members of your technical communication audience. The transcript for my own recent eSeminar with Adobe on accessibility and technical communication is not yet ready, but I will tweet the availability when it is.


Don’t feel lonely in your quest for knowledge. There are communities out there full of awesome helpfulness and knowledge. Sign up for the discussion list at WebAIM to start learning today! You can also start following this Twitter list of great accessibility resources. I started following many of these people when I opened the @stcaccess Twitter account in late 2008. I credit them for much of what I know today.

Education and Standards

Even though you can go far on your own, structured training can give you more focus.

The Accessibility for Web Writers series at 4 Syllables from Australia gives you the fastest education. It goes into depth about many of the issues I raise in this article and in the eSeminar.

My favourite recommendation is the book Just Ask: Integrating Accessibility Throughout Design by Shawn Lawton Henry. It’s available in print, too, but being freely available online makes the information truly accessible to all.

The newsletter from University of Minnesota in Duluth is an education unto itself. It’s one way to get digestible morsels each week on topics like typography, information architecture, usability, and of course, accessibility. It is maintained by @laura_carlson, an incredibly knowledgeable person worth following on Twitter.

Depending on your level of geek, try the Opera Web Standards Curriculum in association with Yahoo! Developer Network for structured training, or the Web Standards Project’s InterACT website. I have heard good reviews of the book they have produced.

Speaking of standards, you’ll need to know about the necessary standards from the W3C. They live at the Web Accessibility Initiative (WAI) site. If you work with software products, you must know the Web Content Accessibility Standards. Every writer should know the Authoring Tools Accessibility Guidelines. Throughout the WAI site, there are educational documents to help both writers and developers.

If you are working with the UK, you will want to investigate the Web Accessibility Code of Practice BS8878 for your business. It costs money, but some businesses may require it.

In connection with the BS8878 standards, Sandi Wassmer, a member of the UK’s eAccessibility Forum, wrote up 10 principles for guiding your work with accessibility.

  • Be equitable
  • Be flexible
  • Be simple and intuitive
  • Be perceptible
  • Be informative
  • Be preventative
  • Be tolerant
  • Be effortless
  • Be accommodating
  • Be consistent

Read the reasoning behind these points on the Copious website and .Net magazine’s article. Then, place these 10 principles somewhere as a daily reminder of what you want to achieve with your acccessible technical communication projects.

Words to Ponder

Learn more about the information I present here by watching the eSeminar – Accessibility in the World of Technical Communication.

I’ll leave you to think about this excellent statement that applies fully to technical communication.

When universal design processes fail to include, consult with, and listen to the people we are actually designing for, we also fail to design effectively.
– from Lisa Herrod

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.
  • Hi, this is a comment.
    To delete a comment, just log in and view the post's comments. There you will have the option to edit or delete them.