The WordPress Foundation, on its website, states that its aim is to "democratize publishing"; and goes on to say that it hopes to "serve the public good through freely accessible software". Of course, they're talking about open source software—accessibility in this sense is simply unrestricted access to the source code. However, as web developers we wouldn't be democratizing anything if a major section of the population were unable to access the content that is being rendered by our software.
Statistics vary, but most studies show that 20% (that's the same percentage, or thereabouts, of websites that run off WordPress) of people have some sort of disability. While not all of them will have difficulty accessing content on the internet, a large number of people will. Some will have to rely on assistive technologies which themselves can only function fully, or to a high standard, when the websites themselves are well formed and actively aid these technologies.
Web accessibility is important, and increasingly so. We would find it unacceptable if anyone, because of a disability, was unable to access libraries, schools, hospitals, or even the supermarket. More and more of our lives are being spent online, and we now commonly communicate with friends, read articles, study, look up healthcare advice and shop on the internet. Internet access is becoming so important that in 2011 UN Special Rapporteur, Frank La Rue, released a report effectively suggesting that internet access should be considered a human right. The bottom line is, access to the internet is important, and so making websites accessible is too.
It makes good business sense too; companies improving accessibility can see a rise in profits, simply because it extends their website's reach. I won't go into this, but the Web Accessibility Initiative has a brief list of case studies you can read through. It also has a section on cautionary tales relating to legal action brought against companies who failed to ensure their websites were accessible. If you're seeking further motivation, there is this article on the overlap of accessibility with SEO. Much of accessibility is about allowing content to be programatically understood, so it makes sense that these same techniques will also help search engines understand and sort content.
Finally the steps you can take to improve accessibility are relatively simple, and the purpose of this series is to take you through the various changes you can make to your plug-ins and themes to help everyone access the internet.
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
— Tim Berners-Lee, inventor of the World Wide Web
Accessibility isn't just about enabling screen readers—there are a range of disabilities that make it difficult for users to access content. These are typically split up into four categories:
While there are a lot of things that the producers of content should be thinking about in terms of accessibility, as developers our role is to ensure the tools we produce for them make this easy, and ensure that we do all we can to ensure to ensure our plug-ins and themes render content in an accessible way. In this series accessibility for us will be restricted to what we as developers can do.
In this series we'll be going over some basic steps you can take to make your theme accessible. We'll be broadly following the Web Content Accessibility Guidelines, and covering the following basic principles:
The fourth principle, which we shall not cover, is Robustness. It is not included in this series, since its principles are general and we'll be discussing specific recommendations throughout the series. Robustness, for the web developer, boils down to the following basic principles:
labeltags, and ARIA attributes).
This series will primarily focus on themes, but will also cover aspects of accessibility relevant to plug-in developers. It will not be an exhaustive list of techniques and recommendations for achieving WCAG compliance, but will focus mainly on relevant requirements of the lowest level (level A), while also including some level AA recommendations. The overall aim of this series is to motivate, and provide assistance in, making your plug-in or theme more accessible. Where appropriate, recommendations will reference the relevant WCAG conformance criteria.