In the last few years, I’ve been thrilled to attend multiple WordCamp presentations where the speakers either focus directly on or mention accessibility in their talks. One of the very first talks of WordCamp Raleigh 2018 was Thinking About Accessibility Before You Hit Publish by NC State’s Brian DeConinck and Crystal Tenan. Their presentation, which showcased how NC State approaches web accessibility on an organizational level, probably had the most audience participation of any talk I attended. The audience discussed and asked questions from all sorts of backgrounds and contexts. And with the CDC reporting nearly 56.7 million, or 1 in 5 (18.7%) people in the United States currently living with some form of temporary or permanent disability, it goes to show that whether you’re a museum, in higher education, a blogger, or a small business owner, the accessibility of your WordPress site and content matters. After leaving the talk, my energy to reflect on and improve the ways Cuberis plans and prepares with museums on content accessibility in our WordPress projects had been renewed.
Planning Ahead For Accessibility
Web accessibility is often a new area for many museum teams we work with on a WordPress project. Whether or not your project has specific accessibility requirements (WCAG 2.0, Section 508, etc…), it’s always a sound practice to plan ahead and consider accessibility from the start. For a refresher, check out our previous blog post on the reasons why accessibility is important for your museum’s website and why it’s more effective as a forethought rather than an afterthought.
To start things off on the right foot, we found that it is important to lead and foster an open and educational environment where questions, concerns, and resources can be easily shared between teams. To achieve this, we:
- Keep a shared repository of relevant web accessibility resources (example: WCAG quick ref).
- Consider and choose the right tools for the project—unfortunately, not every WordPress theme or plugin is created with equal access.
- Note useful functionality offered through commonly-used WordPress plugins (example: readability score offered by Yoast SEO).
- Try to keep it simple and encourage questions!
The important thing to remember is web accessibility is not one person’s responsibility–it’s a shared responsibility which permeates everyone’s role on a project. More recently and with more frequency, our WordPress site trainings have been including the above to help get everyone on the same page and to help content editors feel confident once they start to add content to their sites.
In The Dark With TinyMCE
When the time comes to adding content in WordPress, everyone has varying backgrounds, expertise, and levels of experience with the CMS. With this in mind, our primary goal is to help guide content entry in a straightforward way, but also with accessibility in mind. For example, WordPress’ native visual editor, TinyMCE, does not provide any helpful direction or guidelines. It’s essentially a blank canvas and anyone can add a video embed fairly easily by pasting in the video URL. But did you remember to add a transcript or closed captions?
In contrast, a video component on a recent project of ours (requiring WCAG 2.0 Level A) has carefully considered custom field group. It contains several custom fields and field descriptions for helping you think about transcripts and closed captions—both greatly improve the accessibility of your video content. This is one of the many ways we help guide content entry with accessibility in mind.
Not only does this provide an easy to use interface when adding videos, it helps guide content editors into the right mindset before they hit publish. Ultimately, the responsibility still remains on you doing additional work to provide captions or transcripts, but at the end of the day, your visitors will greatly appreciate the effort and your video content will reach a wider audience as a result.
Accessibility Tools For Content Editors
Before hitting the publish button, having a few tools in your belt is invaluable if you’re looking to ensure it reaches the widest audience possible. Analyzer tools will not catch 100% of accessibility issues or fix them for you automatically but they can help you identify any common or major issues and also provide recommendations on how to correct them. That being said, I’d like to briefly introduce you to a few of our favorites web accessibility testing tools we recommend to clients or use on our projects (either for content entry or quality assurance testing).
- On-screen accessibility analysis (WAVE, tota11y, HTML_CodeSniffer)
- Content readability (Yoast SEO Flesch reading ease score, Hemingway)
- A screen reader (VoiceOver, NVDA, ChromeVox)
Using a combination of these tools in your content editing workflow helps develop good habits and awareness of common accessibility problems found on the web today. Screen readers are in my opinion the most difficult tool to get started with. If you’re just getting started, try a few of the on-screen accessibility analysis or readability tools and gradually learn how to use them before jumping into a screen reader.
Note: most of these tools are independent of WordPress and are useful for checking any website or content.
WordPress Accessibility Today & Tomorrow
There’s no question about it—web accessibility is a difficult landscape to traverse. If it’s not something you’re already familiar with, reading through the WCAG spec or getting started with a screen reader can feel like a daunting, insurmountable feat. It requires practice, patience, and most importantly, empathy. Luckily, you don’t have to go it alone when we work on a project together—we’re thinking about accessibility way before hitting the Publish button.
However, there’s more work to be done! In order for Cuberis to continue improving, we look forward to how the Make WordPress Accessible Team will be improving WordPress core and its accessibility in the future. The examples set forth by this team will ultimately inform and trickle down to the communities who build and publish with WordPress. And with WCAG 2.1 finally published as of June of this year, a more modern guideline set is here to help us make websites even more accessible.