A square image with four smaller squares inside, each a white image against a blue field. The images are line drawings of common symbols. Top left is the handicapped symbol, bottom left is the deaf/hard of hearing symbol, bottom right is the blind/visually impaired symbol, and top right is the mental handicapped symbol.

BACKGROUND

I’m currently working for a company that manufactures payment terminals, and, due to some interesting events in my life that coincided with this, have been thinking about how my friends and loved ones with disabilities would view my work.

Because of the manner of my work, I’m in a unique position to implement accessibility standards in this company. I’m re-working the company’s documentation delivery process, getting all of their content set up in Madcap Flare so they can use and reuse content in an effort to save time and effort in future documentation tasks. This opportunity, intersecting with my current interest in learning all about accessibility standards and ways of implementation, is allowing me to help get this company set up to succeed in the future with, full Section 508 compliance.

In parallel to this Madcap project, I’m helping to create a style guide for the company to use, and I can include 508 compliance standards in that guide as we go forward.

WHY CREATE ACCESSIBLE DOCUMENTATION?

Ask yourself why you create documentation. What are your goals? What do you want the end result to be? Generally speaking, most of us want to create documentation that is:

  • Easy to navigate
  • Easy to read
  • Provides useful information that cannot be found in the UI.
  • Allows users to interact with your documentation and provide feedback.
  • Leaves users with positive feelings about the product and the company.
  • Reduce the number of times a user needs to call in for assistance.
  • Save the company money on support calls.
  • Drive revenue for a company/product by providing valuable information for potential customers.

All of those answers, all of the major goals of TechComm, also provide the answer to the question, “Why create accessible documentation?”

  • If a blind user cannot navigate your documentation, it is not useful to him/her.
  • If a color-blind user cannot read your documentation because of your font color choices, the documentation is not only inaccessible, it’s useless.
  • If a dyslexic user is not able to easily read your documents, you aren’t accessible.
  • If a deaf customer has to call in on a TTY for support because all of your documentation is in video format, you aren’t accessible.

Essentially, if you have even one customer that cannot use your documentation in the way it is intended, your goals as a technical communicator are not being fully reached.

GOVERNMENT COMPLIANCE

If your company provides services to the United States Government, you NEED to be compliant with Section 508, it’s required. I hope the posts I write over the following weeks/months will help you to do that.

THEY DON’T TEACH THIS STUFF IN TECH WRITING SCHOOL!

Unless you specifically sought out information about accessibility when you were learning how to be a Technical Communicator, you probably had no idea that documentation accessibility was even a thing. I know I didn’t, and none of my professors even brought it up. That’s why I’m writing these articles; I know there are others out there, like myself, who want to provide accessible documentation, but don’t have a clue how to do it. If you’re one of us, subscribe to the blog via RSS, or follow me on social media to see when new blogs are posted.

WANT TO KNOW MORE?

Expect a flurry of posts from me over the following weeks about implementing Accessibility in your own documentation, and please, feel free to add anything, ask questions, and generally post whatever in the comments!

Leave a Reply

Your email address will not be published.