Bake it in!
In an age where more and more lawsuits are filed for ADA noncompliance, building with accessibility as a priority rather than a retrofit is, I believe, the way to proceed henceforth. In constructing a new website in the Divi theme, I decided to bake in accessibility as a goal.
Divi is not 100% accessible out of the box, but thanks to CampusPress and their Divi Accessibility plugin (only available via GitHub), the process from the onset was smoother. I installed a variety of accessibility plugins – some were a waste of time. In contrast, others had specific strengths that, combined with others during development, hastened my ability to move toward the WCAG2.1 AA compliance goal.
What is WCAG?
The WCAG (Web Content Accessibility Guidelines) are robust and comprehensive guidelines to make your website accessible to disabled individuals. WCAG was developed by the World Wide Web Consortium (W3C)—the people who invented the Internet and provide the optimum standards for coding best practices. The goal of the W3C is to standardize the web and, with its standards and guidelines, move the Internet to become accessible to all.
I’ve previously written about WCAG2 AA compliance; at one time, my previous website tested compliant at its launch with the old standard. I was able to add seals to my site. But I have learned that compliance is not a one-and-done certification. As a site evolves, ongoing effort must be made to attain and retain compliance. That is especially true with the latest WCAG2.1 AA standard.
WCAG2 guidelines were established in 2008. WCAG2.1 was published in 2018. Within each guideline, there are scores for levels of compliance: A (minimum), AA (good), and AAA (best).
WCAG2.1 AA has over 50 checkpoints characterized by 4 Principals:
- Perceivable – If the disabled can access the Web equally, all information and user interface components must be perceived by at least one or more of their senses.
- Operable – People with disabilities must be able to operate the website, provided with operable interface and navigation components.
- Understandable – If those with impairments don’t understand what your website offers, it is inaccessible to them. Users must understand the information as well as the operation of interface components.
- Robust – When the content is robust, users have more options, and a wide range of disability issues can be answered. Those with disabilities must be able to access the content as technologies advance.
Source and additional information: W3 Web Accessibility Initiative (WAI)
The Build aka Baking Process for WCAG2.1 AA
As I built the site, I paid attention to apparent errors and contrast errors. I used an interesting plugin called Accessibility Checker that displayed status of the page dynamically as illustrated below:
Errors: An error can occur quickly with something as simple as following an H2 tag by an H4 without an H3. In recent years, I have quickly advised others that “headings” versus paragraph text are not only for visual design. For those using assistive devices, the heading tag indicates document structure. It’s a habit to be broken. If one wants a page to emphasize a heading in large type, then even an H3 title, it is not difficult to control styling for that instance. Pages should only have one H1 tag — for the page or post title. And then sequentially, headings should either have multiple heading sets to nest hierarchically or simply go down in the correct order.
As an example, this post displayed on the frontend using the CampusPress Divi Accessibility Tool and output for Headings:
Contrast Errors: Yes, I had to change some of my design decisions with softer colors that are pleasing to visual design for those with normal vision. This is especially true with my official brand color palette. But I am happy that background to foreground contrast ratios was maintained at a minimum of 4.5. I changed a lot of buttons and titles where I thought it was “pretty” to have a teal background with a bold white text foreground. Nope. Insufficient contrast.
Warnings: Displays of potential problems that might be incurred with other testing and warrant further investigation. It’s possible to “ignore” a warning and annotate a reason.
Again, even with a 100% score with this tool, one cannot assume the page or website is accessible. More must be done, and that includes, ultimately, securing user testing.
The WebAIM WAVE (Web Accessibility Evaluation) tool
examines code and page content when previewing or viewing the front end. The WebAIM WAVE app can be added to Chrome, Firefox, and Edge browsers. There is also a standalone tool available on their website.
I had to remember not to allow the top admin bar to display when viewing the front end (this is a setting in the user profile) as those threw false positive errors into the works. Also, the Divi Accessibility Master plugin has a terrific setting that enables a frontend tool and a simulated screen reader wand.
Compelling compliance systems, as third-party subscription services, can be added to a website to ensure ongoing compliance as new content is added such as:
A Warning About Accessibility Overlay Widgets
There are so many accessibility plugins that one can add to a WordPress website. However, after attending numerous workshops and listening to legal experts, some of these tools may complicate matters for those with genuine accessibility needs. For example, during construction, I installed a terrific widget tool called WP Accessibility Helper, but I no longer display it on the front end. Instead, I use its attachment control panel on the back end to ensure that I have provided ALT text for all images or those used for design only as “decorative.”
Please read this article Why Accessibility Overlay Solutions Fail to Protect or Serve.
According to UsableNet’s 2021 ADA Digital Accessibility Lawsuit report, over 400 lawsuits were filed against companies using widgets or overlays, stating, “These solutions do nothing to make a website more accessible for the blind.”
Source: https://www.accessibility.works/blog/avoid-accessibility-overlay-tools-toolbar-plugins/
Related Content:
Accessibility Added as a Service