Accessible Content: What software can and can't do for you

There are some things accessibility software can do, such as run automated tests for color contrast or check for proper code formatting. Your web developers need to follow rules when building templates within your CMS to ensure pages have the right ARIA landmarks and dynamically inserted elements have the appropriate structure. And designers should be making thoughtful decisions when producing designs to ensure good contrast between text and background colors. 

That is mostly where the responsibility ends, however, for your web team. Everything else—properly nested headers, descriptive link text, correct use of lists and tables, form navigation and so much more is actually the responsibility of your editors. These are the people entering and editing your site content.

Automated Tools

Numerous automated tools are available to help editors identify accessibility issues as they work, including:

• The a11y module for Drupal
• Browser tools such as Google Lighthouse 
• Third-party subscription services like SiteImprove

Unlike spellcheck, though, none of these tools will automatically correct the issues they find (which may not be everything). AI is getting better but there has yet to be any quick fixes to be found. For example, AI can’t change a link that says “click here” to something descriptive about the resource being linked to. 

CMS Configuration

A content management system like Drupal is built with accessibility in mind. But it can't bring a site into compliance all by itself. Consider Drupal’s core Media module. By default, Media will ensure every image is displayed with alt text by making that a required field. One of the most common accessibility violations is not having any "alternative text" (aka "alt text") entered for a visual image, which describes for non-sighted users what the image is showing.

Media can be configured to require an editor enter "something" in each alt text field. What it can’t do is compose the alt text itself with a meaningful, contextually-accurate description of the image.

Another example is use of HTML Headers. To be accessible, a site should use HTML headers like H1, H2, H3, etc. in descending order to indicate the priority of content, and give users a quick means to tab between relevant content. But without training, editors often don’t realize this additional purpose of various HTML elements. They're not simply for visual formatting. As long as your editors think the header tags H1–H6 are only for making type bigger (a formatting concern), your site will be rife with accessibility errors.

Some platform-specific tools can be configured to prevent the publishing of content until accessibility issues are resolved. This can be helpful; it can also be the source of frustration and bottlenecks if the people tasked with creating web content have no accessibility training.