Accessibility checks help you optimize your website. For every visitor. By thinking about accessibility, you are actually thinking about your design, the use of textual and multimedia content, and the structure of your website. The World Wide Web Consortium (W3C) has a list of accessibility checks for you. In this post, I will dive into the main, priority 1 checkpoints in that checklist and see how these apply to a modern (WordPress) website.
Priority 1 Accessibility checks
Let’s start at the very beginning of that list of accessibility checks and work our way down.
This is actually quite an extensive check, so I get why they made it the first one. For every non-text element, you should provide a textual equivalent. That goes for things like images, but also for everything ranging from image map regions and animated GIFs to stand-alone audio files and video. This can be done with
longdesc tags, for instance. For your YouTube video, it can be done by adding closed captions to your videos:
It’s not that hard if your video isn’t too long. This goes for any kind of multimedia presentation, by the way. It might be easiest to simply add additional text right below a video or powerpoint for that matter, outlining what is in the multimedia presentation, so screen readers will have no trouble explaining what the presentation is about. If time, or viewing time, is an issue (for instance in online tests), synchronize the text with the multimedia presentation.
On a related note, be sure to change these textual equivalents when the non-textual part changes. That seems logical, but just don’t forget to do this.
Mind your colors and contrast
We’ve discussed this before. There are many ways to check contrast and if colors work together. Quick test: convert your website to black and white. Create a bookmarklet using this snippet:
One of the things that really draws my attention lately is the number of links that just have that different color and no other indication that a word or sentence is linked. I might be nostalgic in this, but sometimes I really feel we should simply agree to underline each link that is in a text (article, page, etc). That would already make a huge difference.
There are things like scripts that cause monitors to flicker more than intended. I have actually never thought of it this way, but there are people that have a serious issue with flickering videos that auto-play or excessive use of animated gifs, let alone blinking text. The sudden flicker (at a certain rate) of the screen might cause what is known as photo-epileptic seizures.
Describe what will happen and make sure this flickering can be enabled/disabled by the user.
Use clear and simple language
This is obviously not just for accessibility, but also for SEO and user experience in general. The Flesch Reading Ease score in our plugin helps you to write better text. This is actually something we’ll be adding much more focus on in the future.
Of course, you should adjust your language to your audience. If you are dealing with serious subjects like law or politics, your text shouldn’t read something like “This new doggyfizzle televizzle gon’ be off the hizzle, fo shizzle.” Adapt to your audience, and make it accessible along the way.
The ‘obvious’ things
There are more priority 1 checkpoints. Let me sum these up for you in layman’s language:
- Add proper
lang=declarations to your HTML tag, but also add these when changing the language in the middle of the sentence, als je begrijpt wat ik bedoel. That can simply be done by adding a
<span lang="nl">in this case. Don’t forget to close that tag to return to the original language.
- If you remove your stylesheet, your web page should still be readable. Here‘s a bookmarklet for that.
- Use client-side image maps instead of server-side image maps. An exception can be when the clickable area is in some odd shape. Remember when we created image maps like that in Dreamweaver? Preferably don’t do that :)
Besides that, image maps need sufficient text links to go with each active region of a server-side image map. More on accessible image maps here.
- Who uses tables, right? Most of us bloggers don’t, and I haven’t seen a design built in tables for a long time (thankfully). If you need a table, for instance for a scientific article, be sure to:
- identify row and column headers, and
- use markup to associate data cells and header cells if your table has two or more logical levels of row or column headers.
- You’re probably not using frames, but in case you are: add a title to each frame so these can easily be identified and navigated as such.
If you really can’t get your website to become more accessible, you really need to check if there is a better theme out there. I can’t put it any other way. Most of the accessibility checks mentioned in this article are not that hard. You should be able to implement most of them, even with little technical knowledge when it comes to creating websites.
I am well aware of the huge pile of crappy themes that are coded so bad that even the slightest change to a CSS file makes an entire design collapse. I have styled my share of themes that could only be changed by me (years and years ago, obviously).
If you really can’t work your way around a (WordPress) theme, and really want to follow these accessibility checks, please provide a link to an “alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.” (Source: W3C)
But I know you are better than that.