Designing and Developing WCAG Compliant Themes

But What Is WCAG More Precisely?

Take the “Web Content Accessibility Guidelines 2.0” as a set of “recommendations” for both web developers and website owners to consider when striving to make their sites easily accessible for all users. Those with various disabilities (visual, auditory, cognitive/neurological) here included.

And “content” here refers to all the elements making the framework and layout: from sounds to text (captions and heading as well), from markup to images, to code. They should follow these well-defined standards to meet the needs of all users, regardless of their disabilities.

Now, if we are to highlight some of the most important WCAG guidelines pointed out there:

• clear “rules” on how to create WCAG accessibility-compliant text: the use of simple language, highly legible fonts, high contrast modes, clearly formatted text broken down into paragraphs, subheadings etc.
• multimedia-related shared standard: video content to be accompanied by its text transcriptions, subtitles, alternative descriptions for all graphical elements, keyboard-only navigation etc.

Why Do You Need a Theme that Complies with the WCAG Guidelines?

For 2 “basic” reasons:

1. going with non-WCAG compliant themes leaves you susceptible to predatory litigation; since 2017 it's been defined in the federal regulations that every website should comply with the WCAG standards
2. refusing to cater to every potential visitor's needs will impact the overall user experience on your website; it's like putting a “Closed” sign on your homepage for some of the users

Furthermore, it's way more convenient to opt for a Drupal theme with built-in functionality from the start. This way, you can jump straight to building your website, knowing that it'll ensure WCAG compliance.
That instead of the scenario where you'd overlook the WCAG accessibility aspect and then, later on, invest/waste valuable resources in making all the due modifications. Only to ensure that your website meets those WCAG standards…
 

Drupal Makes It Easier to Ensure Accessibility: Here's How

And it all started with Drupal 7 and evolved tremendously in Drupal 8.

Basically, the Drupal community committed itself to “turbocharging” the CMS with extensive support for meeting accessibility standards that helps both:

1. developers achieve WCAG 2.0 compliance when building websites
2. end users, for which the content structure —now hardcoded with more meaning — gets easier to understand and, therefore more... usable

In short: Drupal 8's built with accessibility in mind, from the ground up.

Therefore, it makes it a lot easier for us, the OPTASY team, to build WCAG compliant themes. But let us briefly outline some of these accessibility-enhancing features in Drupal 8:

Aural alerts

The “Drupal.announce()” method enables us to alert the visually impaired users of any updates taking place on the page in a non-visual way. An aria-live element informs the visitor of an alert box popping up on the page, all while providing the due instructions to the screen reader that he/she uses, as well.

Accessible inline form errors

Drupal forms have become 100% usable for all visitors; they provide both successful submission and inline error messages that can be understood by all users, irrespective of their disabilities.

Semantic markup in the core

And this is the enhancement in Drupal 8 with the biggest impact on the experience of all those visitors that depend on assistive technology for navigating on your website.

Moreover, it empowers us, the Drupal WCAG compliant theme developers, to control where those semantical elements should be placed on the website. Furthermore, when used correctly, these semantic components HTML5 let browsers and screen readers know what type of content they're actually processing. And how it relates to other pieces of content on your website.

Controlled tab order

The TabbingManager in Drupal addresses those site users that can't rely on a mouse to move around a website. What it does is define a logical and explicit tab order that prioritizes the main elements on a page.

Fieldsets

Fieldset labels can turn out to be priceless for enhancing the experience of those users with cognitive disabilities landing on your website. How? They're used as systems that segment forms into multiple subsections, making them easier to be understood.
 

How We Implement WCAG In Our Themes: WCAG Accessibility Best Practices and Techniques

For, no matter how robust Drupal's out-of-the-box support for web accessibility might be, in the end, it all comes down to how we, as a WCAG agency, manage to implement all those built-in features.

To follow all the accessibility best practices.

And our in-house workflow for building Drupal themes compliant with the WCAG requirements. Standards are slightly different depending on whether:

• we're building the theme from scratch
• we're auditing an existing theme, to detect accessibility issues and improve it

That being said, our theme development process for the first scenario includes the following steps:

1. as a WCAG agency, we stick to the best practices in terms of accessible design: providing high contrast, designing large-sized buttons, links, and controls, designing clear layout with neatly structured content, styling interactive elements (e.g. links) so that they should be obvious by their other particularities, as well, not just by their color, including inline error messages, designing clear and consistent navigation options, etc.
2. an OPTASY WCAG consultant (or a team of them) then runs intensive tests (relying on Gulp) on the front-end code to identify any accessibility issues lurking there
3. next, we test individual pages to make sure that the content and the code entered in the CMS deliver web pages that ensure Drupal WCAG compliance

Needless to add that if it's an existing Drupal theme that we need to apply all the due modifications to so that it should meet these standards, our process would:

1. start with making a list of all the pages on that website and testing them thoroughly
2. then, with the list of accessibility issues at hand, we’d identify whether it's a  theme bug or a piece of content wrongly  implemented that's causing them

It's only then that we get to work, setting that theme against the WCAG guidelines and adjusting it accordingly.