This article was initially posted as a guest blog on The Digital Echidna Blog on November 29, 2016.

So you’ve gone all out on making your website accessible. You considered accessibility at every stage of your project. You started by choosing Drupal. You then evaluated the wireframes for potential problems, took careful consideration that the colours had sufficient contrast, had your developers do regular accessibility checks with every sprint, brought in an external reviewer at the end of the project to evaluate your work, etc.

It was the textbook example of how you should approach building a modern site using a Content Management System.

Then you hand over this gem to the content editors.

And quickly the accessibility gains you have worked so hard on start to be compromised.

Editors copy/paste bad HTML from Microsoft Word and break functionality. They use font tags to mark-up their document or start inserting H1s in the body of the content. They upload images without alternative text. These are just a few random errors that slowly start getting added to the site.

Sure, you do an accessibility review of your site every six months using a third-party evaluation tool. It hits some of the errors that are being added, but by the time it takes you to organize and address these issues, some of those folks who added that content are no longer doing that job. Now someone else needs to be educated about both the problem and the solution.

This is really a best case scenario. Content Management Systems were designed to enable people with little or no technical knowledge to create and maintain content without knowing anything about HTML or accessibility. So why are we surprised that they haven’t grok’d* the WCAG 2.0 specs? (*editor's note: this means 'understood' for the less technically inclined amongst us!)

Fortunately, there is a solution, and we've already done a lot to implement it in Drupal 8.

Authoring Tool Accessibility Guidelines (ATAG) 2.0. ATAG 2.0 is just over a year old now and it comes in two parts.

Most content management systems really struggle with the first part: making the authoring tool itself accessible. Fortunately, we’ve been working on this since Drupal 7 and we can be very confident that users of all abilities can perceive, operate, and understand Drupal’s admin pages in a robust context. Drupal 8 isn’t perfect, but this commitment to make both the front and back-ends respect WCAG 2.0 AA is still, sadly, quite unique.

The second part comes from finding ways to make it easier for content authors to produce accessible content. We know that people learn best when they are corrected while creating a document, rather than a few months later. Drupal can make it easier for authors to improve their content as they are creating it.

There are a few bold things that we’ve done in Drupal 8.

• Alt tags are now required by default. This can be disabled but, by default, editors will be asked to create alternative text for every image;
• We chose CKEditor for Drupal 8, which has a long track record with accessibility, including ATAG. It defaults to semantic markup where possible;
• Headings and spans are now allowed by the default filter for body text. Headings help manage a hierarchy while spans allow for WCAG 2.0’s Language of Parts;
• Browser spell check is enabled by default. Screen-readers aren’t good at pronouncing spelling errors;
• Summary and caption elements have been added to Views tables. This additional information can be very useful in providing additional context to assistive technology users; and
• We have accessibility information added to help pages to help make the information more discoverable.

There is a lot more that can be done, but the groundwork has been set in Drupal 8 to help content editors produce better content for less. Better, more understandable content will not only help people with disabilities, but everyone who needs to access information in this fast-paced, mobile world.