In a recent post titled “ADA Accessibility Compliance for College and University Websites,” the question of how to ensure WCAG 2.0 compliance was covered briefly. In this post, I will expand on a couple of the challenges of making an existing website compliant.

A trip to the theme park

Bringing an existing website into compliance can be extremely tedious depending on the technology it was initially created with, any subsequent patches to this technology, and any themes, plug-ins, or modules which extend the site’s functionality.

For example, let’s consider an existing website using WordPress, which by some accounts powers 26% of the Web, and commands almost 60% of the Content Management System (CMS) market share.

While WordPress is a great open-source CMS, and affords you lots of control over the content being generated, their ecosystem does not come without caveats.

On top of WordPress’s back-end core of functional code and database, sits the visual design in the form of theme templates. While the WordPress Accessibility Coding Standards state that “All new or updated code released into WordPress core and bundled themes must conform with the WCAG 2.0 guidelines at level AA,” note that this policy covers only core code and themes that come bundled with WordPress. In our experience, most sites tend to use custom or third-party themes, and not the bundled designs. There are many marketplaces offering themes, and even the bundled themes can be copied and customized.

Given this, and the fact that the WordPress theming system was created back in 2005, one must be careful to fully research and vet any themes for WCAG 2.0 compliance before employing them on the web.

Plugged into the tedium

A main feature of the WordPress environment is a modular “plugin” system, where the more technically solid central software core, has its functionality extended by the use of user-contributed plugins. As of this writing, there are 53,755 plugins available for download. While some plugins are done very well, quite a few of them are of dubious quality. Even those that are executed well occasionally need to be configured (or even modified) to be fully compliant.

While the template code for a recent project was compliant, one particularly popular social media plugin was generating non-compliant code. Specifically, the plugin was causing 42 unnecessary WCAG 2.0 errors by inserting Instagram and Twitter posts into the page which had incorrect markup. A check of the plugin’s settings revealed that there were no options for compliance. In a situation like this one has two options: find another plugin; or modify the plugin to generate compliant output. The former case adds a time component, as new plugins must be selected and vetted, and may require design changes. In the latter case, one must remember that any modifications to the plugin will have to be reapplied any time the plugin is updated—at least until the plugin’s authors add compliant features.

Before employing any plugin on your website, we recommend that you verify the output being generated is WCAG 2.0 compliant.

Gotcha!

There are many other “gotchas” to consider when working to bring an existing website into compliance. In some cases—such as older websites still using Adobe Flash or other aging/deprecated technologies, or proprietary CMS systems—the consideration of more modern ways of authoring and serving content may signal the need for a comprehensive architectural review and bottom-up website redesign.

Light at the end of the tunnel

As mentioned by the author of the original post, the best way to ensure a compliant website is to build it correctly in the first place. If you are fortunate enough to be able to start anew (or with a fresh redesign), why not move ahead confidently, aided by an experienced partner with knowledge and best practices gleaned from multiple higher ed projects.

So, rather than wait while your internal staff struggles to patch a brittle system, engage a partner with deep experience to more quickly bring your web properties into compliance.