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.


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:

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

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.


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.


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.


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. Required fields are marked *