Presented at the Cowichan Valley WordPress August 2018 Meetup. This presentation was all about web accessibility, thinking about the users affected, technology involved, creating accessible content in WordPress, and finally, choosing accessible themes and plugins.
The first part of the presentation is pretty much a rehash of previous presentations, the second part on content is similar but focuses specifically on WordPress. The last part is almost all new content specific to WordPress.
Slides
What is Web Accessibility?
We’re here today to talk about accessibility, but what is accessibility? One definition, and what seems to be the most common one is that
Web accessibility means that people with disabilities can use the Web. – W3C Web Accessibility Initiative (WAI)
Normally, the next step might be to define a disability. Unfortunately, that’s actually a really hard task, but we can look at the different types of disabilities to get a better idea.
Types of Disabilities
- visual: other than blindness, this might also refer to people who have difficulty with judging distances and hand-eye coordination
- auditory: other than deafness, this might also refer to other hearing issues, such as having difficulty focusing on a single voice
- physical/motor: examples include not being able to grip something or problems with precise movements
- touch: namely this refers to a lack of sensation with touch
- learning: is a rather large umbrella term, but includes dyslexia and other reading disabilities, as well as dysphasia and related issues with writing
With all the different types of devices used to access websites, any one or a combination of these disabilities may apply to a user trying to access a website.
Why Should You Care?
So now that we have an idea of the group of people we’re referring to, why should we care? People with a disability are a minority, and not all of them need special consideration for web accessibility, right? While that may be true, you might be surprised by some of the facts.
Disability > Minority
According to the last Canadian Survey on Disability, 1 in 7 (~14%) of Canadians 15 years or older reported a disability. To help put this into perspective, the number of people with a disability is larger than any single group of visible minority.
Policy & Legislation
Bill C-81 aka Accessible Canada Act went through a first reading back in June. While that’s no guarantee for passing, it was one of the election campaign promises by the current federal government.
Accessibility for Ontarians with Disabilities Act (AODA) requires Web Content Accessibility Guidelines (WCAG) 2.0 Level AA with a couple of exceptions by 2021 for all public institutions and large private and non-profit organizations. Canadian Human Rights Act which ensures equal opportunity but applies only to organizations with federally regulated activities. All other organizations fall under provincial or territorial law. Though due to a court case, the Standard on Web Accessibility came into effect for all department and agencies in the Government of Canada in 2011, which also outlines the requirement to meet WCAG 2.0 Level AA with a couple of exceptions.
Beyond legislation itself, there may be policies at particular organizations, and as requirements of grants or sponsorships for specific projects, also often requiring WCAG.
Unfortunately, I don’t have time to go into WCAG today, but I do have some blog posts about it and if you need your site to be web accessible, WCAG 2.0 or even the new 2.1 would be the guidelines to meet.
Getting Buy-in
People frequently ask me how to get buy-in from others, because they might be convinced that we should care about accessibility and do something about it, but too often, accessibility is put aside because it’s too difficult, time consuming, or due to a belief that “accessible websites are ugly.”
On a side note, this last excuse is not true. I mean yes, some accessible websites are ugly, but in the same way that some websites are ugly regardless of the level of accessibility. If anything, the most accessible websites I’ve reviewed have been fairly pleasing to the eye.
In any case, there are numerous reasons you can present as benefits for putting into practice the methodologies presented, including that they:
- reflect institutional mission, leadership, and values,
- serve all users, – not just those with disabilities, and I’ll talk more about this
- make sound fiscal policy, – since it improves efficiency and reduces costs while maintaining quality, avoids retrofitting, avoids inequitable solutions, avoids litigation; frequently fulfills grant/contract requirements – and
- add value to the institution. – because you have better content, it benefits more people (e.g. captions help people with varying language skills), easier to maintain and update, and higher compatibility with various software and hardware.
Of course, knowing why doesn’t tell you how to approach accessibility.
Approach to Accessibility
Whether you want to, or because you’re told to, half the battle seems to simply be figuring out your approach. If, like many others, you see accessibility as something at the end of a checklist, then that’s when you’ll deal with it.
Accessibility often gets pigeon-holed as simply making sure there are no barriers to access for screen readers or other assistive technology, without regard to usability. – Whitney Quesenbery @whitneyq
Just because something is accessible does not mean it’s usable, but first, let’s also take a look at her point on “assistive technology”.
Assistive Technology
Say as part of your approach, you want to make sure your content is accessible to all assistive technology. You start with ‘screen readers’ on your list, and do some searching and start adding, other ‘text-to-speech’ software, ‘screen magnifiers’, ‘joysticks’, what about ‘mobile devices’ with the added accessibility features? What about ‘keyboards’ for keyboard accessibility? Is there anyone who doesn’t use a keyboard or touch screen regularly?
At this point, you might realize that:
All Technology is Assistive Technology. – Sara Hendren @ablerism
We are not creating content for a specific piece of technology, we can’t. Nevertheless, we can keep in mind the different ways users might interact with our website.
Content Guidelines
When creating content, there are a few simple guidelines you can follow to make your content more accessible.
General Writing
Let’s start with some general writing tips.
- use consistent language
- write out acronyms the first time you use them
- clear and concise
That’s it. Well, okay, not really, but those really are the only ones that are specific to writing style or the use of words. All the other guidelines I will cover are more about structuring or marking up content.
Headings
The first one I want to cover is headings.
Imagine you’re writing a report. Think about how you would structure the headings. You’d have your title as a header 1, your various topics as header 2, and any subtopics as header 3. You might even have header 4, 5 or 6 depending on how much you break down each topic. Now apply that thinking to how you structure content on a web page.
- Header 1 (Title): Making Content Accessible
- Header 2 (Topic): Creating Documents
- Header 3 (Subtopic): Using Headers
- Header 2 (Topic): Creating Media
Issues will arise if you rely on font size or bold instead of headers, or if you use the wrong header level.
In WordPress, simply make sure to use the dropdown and select the appropriate heading or in creating the HTML code.
Links
Links, such a common thing, so it’s simple, but important.
The text for every link should be descriptive and generally, unique within a single page. Imagine there was no other text around it except the title of the page, would you understand what that link is for? If you can’t do it yourself, don’t expect others to.
Media
Let’s talk about media.
Images
When you include images, you also need to include alternate or alt text, which allows you to include descriptive information about the image. While the text is not visible to most users, assistive technologies will read the alternate text as a description of the image, so write concisely, while still providing an accurate description of the image.
The important point is that your description should be what the image is trying to convey. A picture of a red panda in one context might describe facial expression and possible emotion, but that same picture in a biology context might focus on size and coat colour to determine age, gender, or health.
Many online systems, such as WordPress, will have a field box for you to enter the alt text when you are inserting the image rather than having to do it afterwards. Alternatively, you can give your image a descriptive caption, which everyone will see, in which case, you can leave the alt text blank.
Similarly, if your image has been included for purely decorative purposes or is itself an alternate to a textual explanation, you should leave the alternate text empty.
If you need to use colours for figures, such as graphs, consider very different, high contrast colours. You can also use a mix of colour and patterns. Just imagine if you printed your document using a black and white printer. Would you still be able to properly understand your coloured figures? Try to also have the data in table format if possible.
Audio & Video
All non-text content, including audio and visual materials should have an alternate, usually text version.
The suggested method for audio is a text transcript. For video, captions are recommended.
In general, text transcripts and captions are also very useful for non-auditory learners and for those whose English is not their first language. Using these two methods should cover your whole audience.
There is also the option of descriptive audio. For those who are not familiar with descriptive audio, it is an additional audio track that is added to a video to describe what is happening.
While descriptive audio is ideal for visually impaired people watching videos, it is generally very costly to make, so it is not usually offered unless it has already been produced. Alternatively, sometime you will find the description included in the transcript or an alternate version of the captions. You would then simply have two options for captions for people to choose from: one with and one without descriptions.
Much like images, if the audio/video is actually an alternate to text, such as in a tutorial where an explanation is already fully explained in text form, then no alternative is required.
Media should also have controls to pause and play. However, these should be built into the system you are using for the most part.
Avoid flashing, or very fast animations and changes. Anything that flashes 3 times in any one second period can cause epileptic reactions.
Finally, nothing on your website should ever autoplay, whether audio, video, or a set of images. Having something automatically change on the site can be very disorienting to users, especially for those who don’t see it happen.
So, to summarize, alt text for images, transcripts for audio, and transcripts or captions for video or video with a descriptive audio track if it happens to be available.
WordPress Sites
Right, so beyond writing content for the site, there’s the site itself.
Choosing an Accessible Theme
Probably the most important is your theme. I highly recommend one of the themes built by the WordPress team, which are named after the year they’re released. Otherwise, also check out themes with the Accessibility Ready tag, which only receive the tag if they pass the accessibility audit done by the theme audit group.
Plugins
When it comes to plugins, there’s WP Accessibility, which will make changes to your theme and content to increase its accessibility. The Accessibility team also has links to a few other plugins that are designed to make other commons features and plugins more accessible, such as Gravity Forms and Twitter feeds.
If you’re a developer, I also recommend checking out their development tools page which has a lot of great resources.
Assessing Your Website
These are just a few tools that I’ve used or heard good things about, but it’s by no means an exhaustive list. If you’re interested, check out the Accessibility team’s list of tools since they have others listed.
Simulation
Evaluation
- W3C validator
- HTML Codesniffer (bookmarklet)
- WCAG Contrast Checker (Firefox plugin)
- WAVE Toolbar
Frameworks
Assessing Plugins
One quick way to evaluate plugins for accessibility is by using an accessibility code evaluator.
So, for example, if we use HTML Codesniffer, even if you don’t really know what it’s is doing or what the details in the report mean. You can turn it on before enabling a plugin, make a note of how many errors it’s showing, turn the plugin on, add some test content if you need to, then run it again to see if that number has increased. Only using a code evaluator cannot fully assess accessibility, but it’s an easy and quick thing that anyone to run.
Accessibility Statement
You’ve made the effort to create accessible content, but what if you missed something? One of the great ways to be transparent and show your efforts in supporting equitable access is to have an accessibility statement.<
It doesn’t need to be long, but simply a statement to say you’ve made the effort and who to contact if someone has any concerns. You can check out the WCAG to see how to make a more official conformance claim, and I found this accessibility statement generator online, which also follows WCAG. If you want something simpler, I suggest looking at public organizations for some ideas.
Take Away
Hopefully you have enough resources to get started, but if you only take away one thing from today, remember that your efforts in making your content accessible can help many others, not just those that are disabled.
Obligatory Cute Animal
Good post! Thanks for sharing information with amazing content.