You probably landed on this post because you are wanting to avoid a lawsuit or a fine. Or, let’s be less cynical, maybe you already appreciate that web accessibility is morally the right thing to do and you are looking for how to make your site better. Whatever the reason, we are glad you are here. 

But here’s the deal. Too often we see those working on making their sites more accessible miss important context and understanding of the bigger picture. This leads to easily avoidable mistakes or wastes time and resources unnecessarily. In the following, we will cover important background information that every developer, designer, content creator, and site owner needs to know.

Once we have the overview and philosophical information out of the way, we will then get into specific advice on how to evaluate and improve the accessibility of your site. 

Let’s go!

Accessibility Is A Continuum

It is ok to admit it. When it comes to accessibility, what most of us are really after is compliance. We want a certificate or a badge that we can proudly display after a job well done. Then, we want to be done and move on.

It’s all about covering your backside and perhaps a fair way of looking at it, but it can really miss the boat. 

My first paid job on the web was while I was a university student where I worked at the school’s Accessibility Institute. I spent my time manually reviewing the university’s hundreds of department websites for accessibility issues and then I would send a report of needed improvements to the ‘webmaster’ of each site. Remember when we used to all be called webmasters? Ha! This was nearly 20 years ago!

And though the web has evolved considerably over the last two decades, the basic principles and guidelines of web accessibility are mostly the same. 

It was here that I heard repeatedly that accessibility is a continuum. It should never be about compliance and it is never as simple as being accessible or not. No matter how accessible your site is, it can always be more accessible to more users. Just as it can always be faster, better designed, and optimized in countless other ways. 

All I’m saying is that please don’t let compliance or some arbitrary score from an automated checker be your actual goal. Compliance is about assessing your site against standards at a single point in time. Accessibility is about the people visiting your site now and in the future.

Your goal should always be to provide the best possible site experience for all possible users. So as you work to improve your site’s accessibility, always keep the user in mind.

Accessibility Is For Everyone

Speaking of users, when we think about web accessibility, we often consider those with visual or hearing impairments first. Complete blindness, vision loss, or color blindness, and deaf or hard of hearing. Certainly, ensuring blind and deaf folks can easily navigate and use your site is a significant part of a site being accessible, but there is more.

Being accessible means those with cognitive disabilities and conditions need to be able to navigate successfully. Complex triple-drop-down mega-menus and sites with compact and confusing layouts are a no-no. Whitespace, fewer columns, and useful headings can make a huge difference.

Being accessible means those with physical disabilities and limitations need to be able to navigate successfully. Can you easily get around your site with just a keyboard or voice control? Are links and buttons big enough if someone has trouble keeping a mouse steady? Is it hard to manipulate multiple scroll bars with content inside a page? Will your auto-play animations potentially induce a seizure or an instant headache to some visitors? 

Being accessible actually means everyone needs to be able to navigate successfully. On all types of devices, with all speeds of internet service, and everything in between.

Accessibility goes hand in hand with the design and user experience of a site. All of this means that the next time a client or site owner comes to you asking to cram one more link into an already crowded menu or to add another animated slider or pop-over to the homepage, use accessibility standards as a way of changing their mind. 

This is a perfect segue too…

Good Design Is Accessible Design

Or is it accessible design is good design? 

If you’ve ever been a part of a home remodel or renovation project, you’ll quickly find that costs are often higher and timelines are often longer than if you just started from scratch with a new house. Doing work like moving plumbing or taking down walls can be intense and expensive. 

Just like a home, retrofitting an existing site to improve its accessibility may in some cases be more costly and time-consuming than just starting over and building new. Many of today’s WordPress sites are complex with a lot of moving parts like page builders with shortcodes and dozens of plugins that may output content too. 

This just underscores the fact that you really must always design and develop for accessibility from the very beginning of any project or new site. You should be able to feel confident that your site will pass the standards before you ever run it through some site checker. 

The Quick Fix Options

With the legal consequences of websites not being accessible making the news more and more, it is not surprising that we are seeing startups and app makers coming out with different solutions that in many cases sound too good to be true. There are WordPress plugins for this too.

These are buttons that you can add to your website that when clicked will pop up a sidebar widget with accessibility tools. Some of the tools often include items like increasing or changing fonts and alignments, changing colors, or contrasts.

Do they work? Eh.

I don’t want to link to them here (so as not to endorse them), but do a quick google search and you will quickly see what I’m talking about. 

Sure, if compliance is all you are after, these tools may help you. But it should be a temporary band-aid while real accessibility fixes are put in place. These seem to focus almost exclusively on the visually impaired, which like discussed above, is only a subset of the ‘everyone’ approach accessibility is really meant for. 

Many of the features of these tools are better handled by assistive technology or even the settings found in all major web browsers, not on the site itself. It can become unnecessary noise. 

I also find these tools to be overwhelming and confusing to use, which definitely, for me, makes them a non-starter. 

Here’s a screenshot of a popular one so you can get the idea. Notice that there are over two dozen clickable options before even scrolling and in such a small area. Ugh. 

Screenshot of an accessibility toolbar application that we don't reccomend.

But hey, the website of this tool claims to guarantee compliance in under five minutes!

Is WordPress Accessible?

The short answer: WordPress sites that follow best practices are accessible. The WordPress dashboard is among the most accessible web publishing tools available. 

The long answer is a bit more complicated. Since March of 2016, WordPress core has had an official policy that all new or updated code released into core must conform with WCAG 2.0 guidelines at level AA. In practice, this may not have always been the case, but there has been increased awareness and education which is starting to pay off. 

In the spirit of accessibility being a continuum, of course, it can always be improved. There are accessibility shortcomings in the WordPress backend, and it is easy for sites and themes to not meet compliance standards. 

A big word of caution here, as a community, we do run the risk of people (and especially enterprise and public organizations) choosing less accessible technologies should WordPress get an inaccessible reputation. Deserved or not. 

Backend Accessibility

I mention dashboard accessibility above, but when we discuss the accessibility of WordPress, we often are really only talking about the frontend output of content for site visitors. Backend accessibility, in the WordPress dashboard, is also important to ensure that everyone can manage and contribute content to sites.

There are two major players in backend accessibility. WordPress core itself is first – and as noted above, over the last few years, the dashboard experience has been greatly improved. 

For example, an audit commissioned by WPCampus of Gutenberg found 90 issues in the block editor of which the majority have been closed as of December 2019 and WordPress 5.3.1. 

The other major player that can affect the dashboard is plugins. The best advice for any plugin developer is to simply use WordPress core styling and UI for all settings and options in the dashboard. No need to reinvent the wheel, and then you will be well on your way to an accessible experience. 

Frontend Accessibility

This is your site itself, and we’ll spend a lot of time here with tips and advice to ensure you have the most accessible site visitor experience possible. 


If you choose the wrong theme, you won’t have any chance of having a compliant site. For years, there has been a growing list of ‘accessibility-ready’ themes that have been reviewed to meet these theme accessibility guidelines

The theme is responsible for ensuring that the markup, layout, navigation, and design elements are accessible. We do occasionally come across themes labeled as ‘accessibility-ready’ that have accessibility issues. It’s painful to hear, but you still must test.

When it comes to themes, one of the biggest impacts they can have on accessibility is the navigation and menu structure. If the top navigation of a site can’t be navigated by keyboard easily or is not friendly to screen readers, you may as well not care about anything else on your site. This should be the first thing you check when installing a new theme. 

If you develop themes, check out this Guide To Creating Accessible WordPress Themes.


You can also quickly make a site inaccessible with the addition of a bad plugin.

Culprits to look out for are any plugins that display content on the front-end like calendars, sliders, forms, page builders, or Gutenberg blocks.

Frustratingly, there is not a good way to know if a plugin produces accessible content without testing it. There is not a list or tag on for free plugins like with themes. 

If you find an accessibility issue with a plugin, the best thing to do is to contact the plugin developer with as much information as possible. We’ve all come a long way in appreciating and understanding the need for accessibility, so most will be more than happy to work on improving it.

I’d also like to see plugin developers produce accessibility statements that publicly share with users where the plugin may potentially impact frontend content and note any known potential issues. This is probably a bigger undertaking than you might expect, but something we are actively working on here at CampusPress. We know that our own plugins and site are by no means perfect, but we are actively working hard on it.


By now, most of us have heard about ‘alternative text’, or ‘alt text’ for short, which is where you put a description of images.

The main thing often misapplied here is that anything ‘decorative’ doesn’t require alt text. For example, background images don’t need alt text. Similarly, if the same content is presented in text near the image, there’s no reason to force someone using a screen reader to hear that information twice. 

Learn more about writing great alt text and decorative images.

Acronyms, Abbreviations, and Shorthand 

As you write content, make sure to spell out acronyms and shorthand. 

For example, the accessibility community loves to use ‘a11y’ in place of spelling out accessibility. This comes from there being 11 letters between the ‘a’ and the ‘y’. 

For those using screen readers, acronyms and shorthand can be particularly confusing, as they can be harder to understand when heard. Especially since some acronyms actually spell out real words, like KISS for “Keep It Simple, Stupid”. You also alienate all readers that may not be familiar with the acronym. 

Contact Forms

Forms are one of the most common items that automated accessibility checkers will “ding” on a site for having problems. Accessible forms is too complicated a topic to cover in detail here, but most major WordPress form plugins have come a long way in doing the bulk of the heavy lifting for you. The best source for more information on accessible forms is from the W3C

From a site creator standpoint, the main things to keep in mind are to actually use all of the fields that the form tool provides, and to ensure that you label every field with something descriptive and helpful, as this is what screen readers will use.


I used to sit in an office where most of the people in the cubicles around me were using screen readers. It could be distracting, for sure, but fascinating (and perhaps good for eavesdropping). One thing that still sticks out to me is hearing the computerized voice say the word “link” over and over and over and over again. The screen readers were saying “link” out loud before reading the text of each link.

This is because those using screen readers use the ‘tab’ key to navigate around a site. This takes you from link to link around the page. This actually makes the links you have on a page the most important content when it comes to helping users navigate.

So, imagine if all you hear is: “link read more”, “link click here, “link next”, “link previous”. 

All this to say, ensure that your links include text that has meaning when heard all by themselves. 

The other big item when it comes to links is to ensure that you identify them with something more than just color. Otherwise, color-blind visitors may not be able to identify links on your site. The simple option is to underline links – this was once default behavior, but designers everywhere have decided something the cool kids don’t do, so it has fallen out of favor. You can also bold or signify a link using some other means (an icon, for example).

Evaluating Your Site’s Accessibility

The best thing you could ever do to evaluate your site for accessibility is to turn off or unplug your mouse and then try and navigate around your site. 

Even better, would be to do the same thing, but also use a screen-reader and a blindfold to try and get around without sight. 

To be fair, navigating by keyboard, and especially listening to screen readers, are skills that can take a while to master, so you may have trouble even on a truly accessible site. But give it a go.

For a screen reader, try the free ChromeVox Chrome Extension, Narrator on Windows, or VoiceOver on a Mac. Most visually impaired folks will use a premium or paid screen reader to best meet their needs, but these free options should do the trick for you.

Once you are prepared to test manually, you are ready to give an automated accessibility checker a try. Our current favorites include:

It almost goes without saying – these tools can’t catch it all and they also may return false negatives. They will require manual testing and confirmation, which is why we suggest getting familiar with keyboard navigation and screen readers first. Some of the tools and checking may also require input or testing from a developer. 

One more note on things to test. It is not just your website that needs to be accessible – your helpdesk and documentation, any mobile apps, social media content, and anything else a visitor or customer may encounter are included too. Yikes!  

Publish An Accessibility Statement

Accessibility is making the news more and more because there are more and more laws and legal consequences around accessible websites. In the United States, the courts are handing out more fines than ever and extending the scope of what must be accessible at a rapid pace. The European Union passed a Web Accessibility Directive that requires member states to pass and enforce legislation with a deadline for all sites to meet minimum standards by September of 2020.  

One of the significant actions you can take to help comply with all of these new laws and regulations is to publish an Accessibility Statement on your website. This is much like the Privacy Policy we have all become familiar with and will soon be a ubiquitous link found in just about every footer on the web. 

In general, an Accessibility Statement should include:

  • A general statement confirming your commitment to accessibility and any standards you used in testing your site.
  • A declaration of how you tested (self-assessments are fine, but also include any 3rd party tools or services used). 
  • A list of any known accessibility issues on your site. It can be ok to have areas that need improvement, it is just important to say so!
  • A preferred way for anyone that finds accessibility issues to contact you.

Some countries may have specific language to be used or additional requirements to include. 

We used the Accessibility Statement Generator by W3C to assist in creating our own statement and policies.

Here are a few examples of other Accessibility Statements in the wild:

WordPress VPAT

If you provide services to governments or enterprise customers, particularly in the US, you may get asked about a Voluntary Product Accessibility Template or VPAT.

This is a lengthy document that essentially lists accessibility standards and asks you to declare how well you meet the standard. Here is an example VPAT published by GitHub.

For those of us selling WordPress services (hosting, plugins, development, etc.), while we can publish VPATs for individual products or plugins that we create, we can’t really complete a VPAT for WordPress itself. This is because VPATs are designed to be completed by those that create the software or application. A VPAT is a contract and often includes commitments to future changes, neither of which any of us can guarantee on behalf of WordPress. 

Luckily, in our experience, organizations requesting VPATs have been understanding of WordPress being an open-source project and have been satisfied with Accessibility Statements after we explain why we can’t provide a VPAT.  

More On WordPress And Accessibility

The above is really just the tip of the Guten iceberg when it comes to accessibility, but we hope you now have a better foundation on which to build going forward.

We will continue to update and add to our WordPress and CampusPress Accessibility resources.

And we’ll leave you with some more helpful links and resources.

WordPress Accessibility Handbook – best practices for content, development, and design as curated and published by the WordPress community.

WordPress Accessibility Team Blog – where the contributors that work to improve the accessibility of WordPress publish updates and news. We encourage anyone interested to get involved!

WPCampus Library – videos of accessibility talks and presentations from WPCampus conferences. Talks – videos of accessibility talks and presentations from WordCamps.

If you’d like to discuss any of the above or reach out for help, please contact us. We’re happy to chat!

About Ronnie Burt

General Manager of CampusPress. A former educator and wannabe musician from Austin, Texas.