I’m not sure if you realize this, but YOU are the thing that is most likely to impact accessibility on a Drupal site. Why? Drupal is pretty darn accessible out of the box. The thing that makes it less accessible is that we (developers, architects, content creators, designers) come in and do our thing and we don’t pay attention to the impact we are having on the accessibility as we go.
This post is all about the common mistakes that are made while building out a Drupal 9 site that are almost guaranteed to impact the accessibility.
Improperly Configured WYSIWYG
The TLDR here is that you want to have very rigid control over what markup goes into the WYSIWYG so that you know the answer to this simple question: “If I do this, will it change my accessibility score?”
A sure-fire way to damage accessibility on a site is to open up the WYSIWYG to allow “too much” HTML. Very broadly, HTML code falls into two categories:
Layout (e.g. divs, tables, spans, etc.)
Formatting (e.g. a, b, i, h2, etc.)
As a general rule, the WYSIWYG should be configured in such a way that “whatever” changes the content creator makes do not have impact on accessibility. Typically formatting changes are safer than layout changes. Here are some examples:
Hard coding a <table> in the WYSIWYG — Tables are inherently fraught when it comes to accessibility anyway, and the additional markup required to make them “accessible” is not something most people are “just going to do”
Adding additional divs, spans, etc. to impact the layout of a page can both impact the mobile performance of a site and the accessibility
Changing colors and sizes (while technically formatting) can also have major impacts on accessibility.
Mitigation: There is an accessibility checker for CKEditor that you can add and enable, which is better than nothing. But this checker is only going to tell you if the markup is accessible or not, it’s not going to necessarily stop you from doing stupid things!
Embedded vs. Files vs. Media
The TLDR here is to ensure that the only way to embed media on your site is via media reference fields and the media embed field in the WYSIWYG. No files, and no direct HTML.
Another common issue is the improper handling of media. I see this manifest in a couple of different ways:
The first is actually very similar to the previous item related to the WYSIWYG: allowing for the direct embedding of media files in the WYSIWYG (e.g. img tags, video embeds, etc.).
The second is using the Drupal File field instead of a Media field.
The biggest advantage of using Media entities for images, videos, documents, etc. is that you can control the display modes of these content bundles. If you can rigidly control the display modes then you can make sure that the markup is accessible. For Images, you can require alt text. For Videos, you can require captions. Again, this is all about control of the content creation and display process!
Also keep in mind that if “all the embedded content images” on the site are using the same template and you DO find an issue, you should be able to go “fix” that issue in one place (the template). If you have a bunch of images (like hundreds or thousands) of images that aren’t using an entity display and you find “a bunch of problems” then you may well have to go hand edit the markup multiple places (like hundreds or thousands of places).
Isolated Design Process
The TLDR here is that accessibility cannot start to be a concern “in implementation.” It must start during the design phase, as well.
The spectrum of things that impact accessibility on a site is pretty broad. Color contrast, opacity / transparency, etc. can have major impact on people that are visually impaired. I’ve been on more than one project where designs got fully approved and all the way through to implementation before anyone checked the contrast of the colors in the design!
Make sure that accessibility testing (particularly the constants and transparency rules) are baked into the design process so that if there are issues in, say, your company’s color branding guidelines that will never pass accessibility that you identify these before developers have spent hours implementing things that cannot pass accessibility requirements.
Requirements Communication
The TLDR here is that “most” people aren’t accessibility experts. Don’t assume that the people on your team “know” what needs to be done. There are also many accessibility standards. Don’t assume everyone knows what “we are aiming for.” Document it!
I’ve worked with folks that know a heck of a lot more than me when it comes to accessibility. I’ve also worked with folks who don’t know anything about it at all. Just assuming that “everyone is on the same page” is a fatal mistake.
There are also quite a few different accessibility standards, and they aren’t all the “same.” So consider on the project if we are aiming for WCAG 2.0 AA or AAA or 2.1 AA or “just Section 508.” The specs for these standards are fairly complex and non-trivial to decode in many instances.
I recommend being very explicit both with the development team in terms of “which” standard the project is aiming for AND on tickets. Any ticket that is doing something to impact markup (including SCSS/CSS, JS, Twig, HTML, etc.) should have at least some accessibility requirements included in the implementation details / acceptance criteria.
Markup Only Testing
The TLDR here is that markup is the low hanging fruit of accessibility. You can have perfect markup and still have a wildly inaccessible website. Make sure you’re also doing keyboard navigation and screen reader testing if you want to have a truly accessible site!
I’m presenting on using Pa11y to automate accessibility testing in just a couple of days at Drupal GovCon 2020! It’s an important part of the build and test process. But it’s not enough. If you want to have a truly accessible site you have to test with a keyboard, you have to test with a screen reader. If you want to have a REALLY accessible site you should also work with an accessibility expert and/or folks with disabilities who would have to truly navigate the site.
As a person who CAN use a mouse, as a person who CAN read the content on the screen, I’m heavily biased by what I can interact with because of my way of interacting. Trying to weed through that bias and ensure that you are presenting content in a way that works for folks that must use a keyboard or screen reader is key.
In Conclusion
Look, accessibility is hard. It just is. It requires expertise that many folks don’t have, it requires a ton of extra testing and focus, and it’s a moving target that can change as standards and policies are improved and updated. And you know what? That’s ok. It’s a part of doing business online. If you think about accessibility in your designs, your content, implementation and make it a focus then it doesn’t have to be the rock that you beat your head against. It can (and should) be an important part of your process. Just make sure you avoid these common mistakes!