It’s important to remember that web accessibility is determined by multiple factors. Developers and designers are responsible for building web accessibility into the code and design of a web site. Content creators – educators and students included – are responsible for seeking out authoring platforms that support web accessibility and using the tools correctly to create accessible content.

If that sounds like opaque geek-speak, you could imagine that developers and designers build a house (the site), and content creators – anyone loading content – furnish it (using pages, text, images, video, etc. ).

Step 1. Start with an accessible theme or website design.

In WordPress, anyone can create a site quickly and easily and all of the backend and styling is taken care of by theme developers. WordPress users just pick a theme, load their content, press publish and share their content with the world – unless they pick a theme that isn’t accessible. *

Not all themes are created equal

Some of the themes available on WordPress (both free and pro) predate concerns about web accessibility. And even now, not all developers consider web accessibility when they build new themes. It’s up to WordPress users to select a theme from what WordPress calls “accessibility-ready themes“.

Screen shot of how to use the filter to see "accessibility-ready" themes in WordPress.
Narrow down your theme choices by filtering for “accessibility-ready” themes.

For example, an accessibility-ready design allows for keyboard navigation – meaning links, buttons and form controls can be controlled with a keyboard (using Tab and Enter keys, for example) for users who can not manipulate a mouse. This isn’t something the average WordPress user would know how to code but you don’t have to because WordPress requires this feature in all themes tagged “accessibility-ready.”

Simply selecting an “accessibility-ready” theme gets you well on your way to having an accessible site. But there’s more to do.

Step 2: Don’t ignore (or work around) accessibility features, use them!

Following on the house analogy, it’s easy to see how developers and designers could do everything right to make a house accessible, but if people fill rooms with too much junk, or put bookcases in front of grab bars, they can block the accessibility designed into the home.

It’s the same for a web site. Content creators need to be aware of the building blocks that make their content accessible so they don’t accidentally block the accessibility of an “accessibility-ready” design.

For example, “alt-text” sounds like code-speak but it’s critical content for people who can’t see the images on your site. The text is read aloud by screen readers. (Incidentally, it is also read by Google which is why well-written alt-text can improve SEO). Prompts are often coded by developers to remind content creators to write alt-text, making it easy for users to make images accessible.

screenshot showing how alt text is prompted on image upload. This alt text describes the image of the theme filters (used above).
Note: the authoring prompt links to the W3C’s advice on writing alt text and reminds authors that images that work to convey information to the reader need alt text. Decorative images (swirls and flourishes) need not be described.

However, authors might ignore a prompt, or choose to work around it by filling in junk text, e.g. “jfogoe” to get around a required field. If the author does not describe the image, the author is blocking accessibility.

You can find a current list of the required features of WordPress “accessibility-ready” themes here.

Note: There are WordPress plug-ins that are designed to help with specific accessibility authoring challenges, but a plug-in is basically a form of remediation and can’t address fundamental issues stemming from an inaccessible theme.

3. Build, practice and model web accessibility literacy skills

So you have picked an accessible design and you have vowed not to work around its built-in features. The last and equally important step is to create and curate web accessible content.

Seven core authoring strategies are recommended by the W3C Web Accessibility Initiative (WAI). These strategies are regularly referenced in technology and compliance literature, but the field of education has yet to categorize or directly engage with the strategies as literacy skills, which I believe they are.

By practicing these skills in the curation and creation of education content and online teaching and learning spaces (website, LMS, Google suite, etc.), educators can improve the accessibility of their course content and model accessibility practices for students.

Need more info?

Much of the literature on web-accessible course materials, assumes educators and learners are consumers of traditionally published content, not active producers of content (National Center on Accessible Educational Materials, 2015).

Web Accessibility Theory and Practice: An Introduction for University Faculty by Bradbard and Peters is one of the most robust articles on web accessibility for educators.

Bradbard and Peters offer excellent background information on assistive technologies that would help any educator understand the rationales for text- or code-based accessibility efforts. They also offer workflow strategies to improve accessibility by work product, for example how to improve the accessibility of PDFs.

That said the specific skills educators need to comply with WCAG standards are somewhat buried. And the article is framed for educators who build their own course websites, which could prove distancing to educators who use their institution’s LMS to share content, or simply curate digital content for course readings.

So what if you aren’t building a website for your course? Coming soon: What can educators do to make LMS-housed courses web accessible?

*This article addresses WordPress users but other template-driven authoring/publishing platforms such as Wix use templates that support accessibility. If you are working with a developer/designer to build a custom site, you need to specify at the development stage they meet accessibility standards, e.g. WCAG 2.0. Remediating a site is costly and time-consuming so the specifications must be outlined at the start.