“It’s the tools, dammit!”: Accessibility and Content Management Tools

I just learned something new – or something new about something old.  I was making a roadmap for a customer, and as part of the roadmap I reviewed the accessibility of their tools. Here is what I learned:

  1. Accessibility support in tools and process is not just important, sometimes it is everything.

  2. Don’t believe everything vendors tell you.

Well okay, you probably knew not to believe product sheets, but I never knew to really, really not believe them.  Of the product sheets and vendor feedback I received, some were accurate, some were close to true, and some were made up with no discernable relationship to reality.  Unfortunately, as a fan of small business, it pains me to say that the smaller vendors were among the less reliable; however, the small vendors who really cared about accessibility nailed it. (Formstack got five stars.)

The reason this is so important is because of lesson 1 – tools matter.  If you are using a content management systems with inaccessible modules or a publishing system that strips out accessibility features to compress files and save server space, then there is nothing you can do to make your content accessible. If you are using a tool that as default uses accessibility semantics correctly, such as sets field labels, form fieldsets, ARIA, accessible feedback, etc., you just need to add an alt tag to your logo and you have accessible content.

W3 Guidelines

I referred to the W3C’s Authoring Tool Accessibility Guidelines (ATAG) for help with creating my roadmap.  ATAG addresses all kinds of authoring tools, including content management systems (CMS), save-as-HTML/PDF conversion tools. I’ve outlined the most critical issues to my roadmap below:

  • Can you make accessible content that fully conforms to WCAG 2.0 using this tool? If not what are the gaps? What types of content are not fully accessible?
  • Is it easy to make accessible content? Do authoring tools currently in use support or hinder the production of accessible websites? Do they use accessibility prompts? Is auto-generated content accessible?
  • Do authoring tools currently in use change or remove accessibility information (for instance, alternative text for images) that has been added by other tools or by hand mark-up?
  • For authoring tools that do not support the creation of accessible content, are there plug-ins or other utilities that can be used with those products to better support the production of accessible websites?
  • What documentation and support exists to help people use this tool accessibility? Do they have a contact person in charge of accessibility
  • Does the vendor commit to accessibility support for future versions?

I would also add the following important points to the procurement process:

  • Who provided the information about a tool’s conformance?  If  the testing was by the vendor, test it yourself or, even better, ask a good accessibility expert to evaluate and test their claim.
  • Are there guarantees provided with the vendors accessibility claim? In a contract, add penalties and a clear time frame to fix any accessibility issues that are found.

Processes are also important. For example, if you are using InDesgin to make a PDF, using the “place” function instead of copy and paste will eliminate a lot of accessibility problems. Copy/pasting can bring in pictures of the content or tables of unstructured text, which will be a nightmare to fix.

In conclusion, make sure your content management tools are accessible.  Each hour spent on accessibility evaluation of tools and processes when you establish your IT process can save you literally months of accessibility remediation later.


Lisa Seeman is a Senior Consultant at Deque Systems and internationally recognized expert in web interoperability, the Semantic Web, knowledge modeling accessibility and web protocols.

update selasa

Leave a Reply

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