WordPress plugins and accessibility

WordPress recently announced that “all new or updated code released into WordPress core and bundled themes must conform with the WCAG 2.0 guidelines at level AA.” This means WordPress will be making the product more accessible with every new update. Rian Rietveld‘s article WordPress goes WCAG clearly reflects her enthusiasm about this step forward in terms of accessibility.

It aligns with Morten Rand Hendriksen‘s statement during the State of Word 2015 (at 1:12:04 to be precise). We shouldn’t just focus on “study Javascript deeply” but also on “study accessibility deeply”.

For us plugin developers, Rian makes a clear statement: “The accessibility of plugins is the responsibility of each plugin author.” In our book, that means you can’t just ignore accessibility altogether, because you don’t like to focus on it. In this post, I’d like to illustrate what this responsibility means to us.

accessibility responsibility

Write clean code

I’m not a code writer myself but have seen my share of plugin code over the last several years. Some are well coded, some are ‘poor’ coded. And by poor, I mean that some drawings by two-year-old kids have more structure than the code of those plugins. Write clean code, it’s as simple as that. It will make sure screen readers and tools like that will do a better job. It will make a site more accessible.

At Yoast, we don’t take this lightly. We have a well-thought-out code design and development process, which contains a lot of feedback moments. That feedback comes from colleagues and for instance from beta testers. It’s our and your responsibility as a plugin developer to make sure you’re not just outputting code. You have to make sure that you’re outputting clean code.

Use (free) accessibility tools

Running your code through the W3C Validator every once in a while already helps you determine if you’re writing clean code. Usually, the recommendations this validator gives you, are easy to fix. And they might already make a huge difference in term of accessibility.

Another great and very easy-to-use tool is WAVE. Simply install the chrome extension and see for yourself:

WAVE accessibility test - chrome extension

The WAVE extension analyses a variety of possible accessibility issues. In the screenshot above, you can see things like missing ALT attributes and contrast issues. And how about adding these labels to your forms? It’s all not that hard. This WAVE analysis is all done in seconds and really tells you where your code (or website) should be improved for accessibility.

Contrast is also something that’s really easy to test and improve. Simply use WAVE or Lea Verou’s contrast ratio tool. No need to do that on a live website, as we’re talking about your plugin’s user interface here. Please go read my post Easy-to-use accessibility tools for more testing tools.

“Your plugin’s not perfect either”

You were thinking just that, right? Our plugin isn’t perfect either, in terms of accessibility. But we have shown to you over the last years that we’re listening and we’re improving accessibility at a fast pace. Just the other week, we took that to the next level by hiring Andrea Fercia full-time. Andrea specializes in accessibility. He’ll also be dedicating a portion of his time to core, by the way.

Andrea is well-known in the WordPress community. He is the team lead for the accessibility team for WordPress when it comes to core. We’re very happy to have you on board, Andrea. I am sure we’ll be making our plugin(s) even more accessible thanks to your knowledge and experience!

I guess that’s what Rian meant when she wrote: “The accessibility of plugins is the responsibility of each plugin author.” As the plugin author of one of the most-used WordPress plugins, we hope we can set an example in this!

Read more: ‘Easy-to-use accessibility tools’ »


The main accessibility checks

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.

accessibility checks

Priority 1 Accessibility checks

Let’s start at the very beginning of that list of accessibility checks and work our way down.

Text equivalents

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 alt or 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:

javascript:(function(){var e=document.body;e.style.filter="progid:DXImageTransform.Microsoft.BasicImage(grayscale=1)",e.style.filter||(e.style["-webkit-filter"]="grayscale(1)",e.style.filter="grayscale(1)")}())

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.

Don’t know how to create a bookmarklet? Check this page. In this post on accessibility tools, I mention more in-depth accessibility checks for color and contrast.


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 your website depends on scripts (or applets)m but sure to test your website with these objects turned off. For instance, if your website uses a loader per page (WHY!?), turn JavaScript off in for instance the web developer toolbar and see if your theme still works. If not, fix this or provide the same information on a separate page that is accessible.

Last resort

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.

Read more: ‘Easy-to-use accessibility tools’ »

Easy-to-use accessibility tools

Is your website ready for the visually impaired? Have you ever tried to navigate your own site without a mouse? Just some of the questions I asked you in my article Accessibility matters. In Joost’s recent article on the Google Webmaster Guidelines update, he explains that these new guidelines also focus more on accessibility. Accessibility does matter, and clearly for Google as well. In this article, I’ll show you some easy tools you can use to make your website accessible for more visitors.

Easy-to-use accessibility tools

WordPress accessibility

If you’re using WordPress, there’s a complete team working on making WordPress more accessible for everyone. From what I can see, this team is working very hard to both make a case for accessibility and improving WordPress accordingly.

I’ve had several conversations with a number of members of this team, for instance during WordCamps (see you in Vienna?) and via Slack. One thing is always a part of those conversations: making a case for accessibility. Accessibility, in my opinion, will too many times be considered as a possible ‘extra’, where roughly 10% of your website visitors will experience some kind of accessibility issue, like contrast or fonts that are too small. If you follow accessibility guidelines, your overall website will improve for all your visitors.

Accessibility tools

We obviously spend time in our reviews testing (a number of aspects of) accessibility as well. Obvious things that are tested are use of headings, contrast and descriptive links. In this article, I’d like to go over these very easy-to-use accessibility tools and show you how you can use these yourself for your website.

Use of headings

Headings and SEO value? It’s up for much debate. Although some people already claim the SEO value of headings is zero to none these days, we’re just not sure yet. But when it comes to accessibility, headings are very important:

Headings add structure and meaning to pages by labeling each content part and indicating the relative importance of those parts.

Of course, this is very much UX related, not just to accessibility. Not just for people with a disability of some kind, by for every visitor of your website. Make sure your headings are descriptive and nested the right way. Don’t just use headings as a design element (“it’s the only way I know how to enlarge my text”) or to impact SEO (“I use all H1 headings, that makes it all very important to Google”). The first one is a plain lazy solution –  and the second one just doesn’t hold that much truth anymore, like mentioned above.

Easy-to-use accessibility tool to test heading structure on your website: Quix. This tool is like the Swiss Army knife of our site reviews. You can test all kind of things by using a variety of commands, but the ones we use most are seo, h and seocss. That last one will show you all the headings on a web page:

accessibility tools: headings test example

Even on pages where we don’t actually can read what’s on there, this little accessibility tool will allow us to check heading structure. As you can see, the content part of this website is structured right, but the sidebar on the left is using a reversed structure. (first H2 than H1).

Read more: ‘Headings and why you should use them’ »


There is a number of ways to test the contrast of a website. By contrast we mean the way the color of a text is readable on its background. When using black on white, you’re obviously safe. But a lot of websites change these colors for sidebars or specific sections or use text on images, for instance in a slider.

When I was building websites myself back in the old days, I often used this handy github page by Lea Verou:

Accessibility tools: contrast ratio calculation

It gives you a contrast ratio score based upon the W3C contrast guidelines, which considers 4.5:1 to be OK. Black text on white background gives a ratio of 21:1, by the way.

The test tool by Lea Verou just tests contrast. If you want to play around with contrast to find how this affects visits by for instance people that are colorblind, you might want to check the Color Contrast Analyzer (Windows/Mac) that checks foreground/background contrast levels and allows you to preview designs as they might be seen by colorblind users. If you’re using a Mac, this little contrast tool by Michel Fortin is also great: Sim Daltonism. Like the Color Contrast Analyzer, it allows you to hover a website and test a number of colorblindness variations:

Accessibility tools: sim daltonism in action

Easy-to-use and fast, I have Sim Daltonism installed on my Mac.

Another accessibility tool I’d like mention here is simply called SEE. It’s a rather confronting Chrome extension, which allows you to view a site as viewed by visitors with variations of colorblindness, but also as people suffering from for instance glaucoma or cataract. Be sure to try that one for yourself as well.

Descriptive links

The last accessibility tool I’d like to mention is right in your computer. Both Mac and PC have ways to read out the text on the screen for you. The text that is read, can be identified and that will show you if a link is set up in a descriptive way. For Windows users, the application that reads text to for instance a blind visitor is called Narrator. As I am using a Mac, let me show you how to identify inaccessible links using VoiceOver. I assume Narrator has pretty similar features. Correct me if I am wrong, Windows user.

There are a lot of keyboard shortcuts that can be used when it comes to accessibility. In our reviews, we do the following:

  1. Press CMD+F5 to turn on VoiceOver
  2. Press Ctrl+Alt+U to bring up the Content Chooser
  3. See if f.i. the read more links say more than just ‘read more’

Here’s the result of that on a blog that did not optimize for accessibility:

Accessibility tools: Testing links using VoiceOver on a Mac screenshot

You can clearly see that Treebeard is the nick or name of the author, but a blind visitor just sees Treebeard. And where we know that the read more is related to Part Deux of the Dumping Dumps article, a blind visitor just sees ‘read more’. About what? Don’t get me wrong: we’re not doing everything right ourselves, but we try to improve the accessibility of our site and plugins as well. Last year, Rian Rietveld wrote an article on how to use a .screen-reader-text class to make your read more links more accessible. Go read. Implement.

One more thing

The people at WAVE Web Accessibility created a nice tool to quickly identify a lot more rights and wrongs on your website. This is done completely automatically and will need a human to see what really are realistic improvements and what not. I don’t consider this a replacement for the accessibility tools mentioned above, but it is definitely worth looking into!

Most of the tools mentioned above and more can also be found on make.wordpress.org/accessibility/useful-tools/

Keep reading: ‘Accessibility matters’ »

Accessibility matters

Usability is important: for everyone. To make sure your site can be properly used by all your visitors (even if they’re (visually) impaired), you have to optimize your site’s accessibility. Every software developer should at least have some basic interest in this. Well-known WordPress accessibility expert Rian Rietveld has trained both our review and development team and although we’re doing a lot of things right, there’s always room for improvement. With every release, we try to improve our software a bit in terms of accessibility as well.

Accessibility matters

What is accessibility?

Accessibility is about how well your software or website can be used by the visually impaired visitor, for instance. Wikipedia puts it like this:

Accessibility refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers).

Accessibility matters

We have an aging population, that much is clear. That growing group of senior citizens is getting more and more familiar with the internet, using iPads and Samsung Galaxy’s to order pizza and book hotels. And set up their own websites. Although we don’t want this, our vision reduces with age. Our website and software need to be accessible for this growing group of visitors.

Of course, there are more visually impaired people, think along the lines of (color) blindness and blurry vision. 285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 have low vision. 82% of people living with blindness are aged 50 and above. Source: WHO.

Color blindness (color vision deficiency, or CVD) affects approximately 1 in 12 men (8.3%) and 1 in 200 women in the world (0.5%). Source: Colour Blind Awareness.
I’ve checked multiple resources: About 50.4% of the world’s population is male, 49.6% is female. With 7.3 billion people currently living on the planet, that means over 300 million color blind males and over 18 million color blind females. That’s quite a lot of people you’re missing out on when you’re not optimizing your website or software for blind or color blind visitors!

I totally get that not all the blind people use the internet and I also understand that not all color blind people need an adjusted website, per se. But it’s really not that hard to optimize your website or software. WordPress has an accessibility team monitoring WordPress. Drupal is working on accessibility. So should you.

It’s not just visual impairment

There’s more to accessibility than visual impairment. Less visible (oh the irony) conditions that can cause accessibility issues include for instance dyslexia (and other reading difficulties) and dexterity difficulties. Severe dexterity difficulties mean users are unlikely to use a mouse, and rely on the keyboard instead (Source: Powermapper.com). Have you ever tried to use your website, or our software for that matter, without using a mouse? It’s a tough job, I tell you.

And let’s not forget about the deaf visitor that wanted to take our Basic SEO training and was facing over 2 hours of videos without subtitles. It’s quite easy to add these, and so we did.

A lot to think about for every website owner, website developer and software developer. And this is just the tip of the iceberg. It’s very likely we’ll follow up on this article with more in-depth information on accessibility. In the meantime, I’d love to hear your experiences in the comments!

Image SEO: alt tag and title tag optimization

Adding images to your articles encourages people to read them, and well-chosen images can also back up your message and get you a good ranking in image search results. But you should always remember to give your images good alt attributes: alt text strengthens the message of your articles with search engine spiders and improves the accessibility of your website. This article explains all about alt tags and title tags and why you should optimize them.

Note: the term “alt tag” is a commonly used abbreviation of what’s actually an alt attribute on an img tag. The alt tag of any image on your site should describe what’s on it. Screen readers for the blind and visually impaired will read out this text and therefore make your image accessible.

What are alt tags and title tags?

This is a complete HTML image tag:

<img src=“image.jpg” alt=“image description” title=“image tooltip”>

The alt and title attributes of an image are commonly referred to as alt tag or alt text and title tag – even though they’re not technically tags. The alt text describes what’s on the image and the function of the image on the page. So if you are using an image as a button to buy product X, the alt text should say: “button to buy product X.”

The alt tag is used by screen readers, which are browsers used by blind and visually impaired people, to tell them what is on the image. The title attribute is shown as a tooltip when you hover over the element, so in the case of an image button, the image title could contain an extra call-to-action, like “Buy product X now for $19!”, although this is not a best practice.

Each image should have an alt text, not just for SEO purposes but also because blind and visually impaired people won’t otherwise know what the image is about, but a title attribute is not required. What’s more, most of the time it doesn’t make sense to add it. They are only available to mouse (or other pointing devices) users and the only one case where the title attribute is required for accessibility is on <iframe> and <frame> tags.

If the information conveyed by the title attribute is relevant, consider making it available somewhere else, in plain text and if it’s not relevant, consider removing the title attribute entirely.

But what if an image doesn’t have a purpose?

If you have images in your design that are purely there for design reasons, you’re doing it wrong, as those images should be in your CSS and not in your HTML. If you really can’t change these images, give them an empty alt attribute, like so:

<img src="image.png" alt="">

The empty alt attribute makes sure that screen readers skip over the image.

alt text and SEO

Google’s article about images has a heading “Use descriptive alt text”. This is no coincidence because Google places a relatively high value on alt text to determine not only what is on the image but also how it relates to the surrounding text. This is why, in our Yoast SEO content analysis, we have a feature that specifically checks that you have at least one image with an alt tag that contains your focus keyphrase.

Yoast SEO checks for images and their alt text in your posts:image alt attributes assessmentWe’re definitely not saying you should spam your focus keyphrase into every alt tag. You need good, high quality, related images for your posts, where it makes sense to have the focus keyword in the alt text. Here’s Google’s advice on choosing a good alt text:

When choosing alt text, focus on creating useful, information-rich content that uses keywords appropriately and is in context of the content of the page. Avoid filling alt attributes with keywords (keyword stuffing) as it results in a negative user experience and may cause your site to be seen as spam.

If your image is of a specific product, include both the full product name and the product ID in the alt tag so that it can be more easily found. In general: if a keyphrase could be useful for finding something that is on the image, include it in the alt tag if you can. Also, don’t forget to change the image file name to be something actually describing what’s on it.

alt and title attributes in WordPress

When you upload an image to WordPress, you can set a title and an alt attribute. By default, it uses the image filename in the title attribute, which, if you don’t enter an alt attribute, it copies to the alt attribute. While this is better than writing nothing, it’s pretty poor practice. You really need to take the time to craft a proper alt text for every image you add to a post — users and search engines will thank you for it. The interface makes it easy: click an image, hit the edit button, and you’ll see this:wordpress image details with alt attributeThere’s no excuse for not doing this right, other than laziness. Your (image) SEO will truly benefit if you get these tiny details right. Visually challenged users will also like you all the more for it.

Read more about image SEO?

We have a very popular (and longer) article about Image SEO. That post goes into a ton of different ways to optimize images but is relatively lacking in detail when it comes to alt and title tags — think of this as an add-on to that article. I recommend reading it when you’re done here.

Read on: Optimizing images for SEO »

The post Image SEO: alt tag and title tag optimization appeared first on Yoast.