Team Accessibility at WordCamp London 2015 Contributor Day

Blind WapuunkIt was my inaugural WordPress contributor day, but it won’t be my last. I wrote about my excitement and planned goals before attending WordCamp London 2015. I have also shared how my first London WordCamp has already changed iFamily’s work week and how we are committed to Happy Mondays instead of the more typical blue start to the working week. Our working week will now get off to a good start by embracing Five for the Future.

What I haven’t shared yet is just how inspiring and worthwhile it is to take part in a .

I wasn’t confident. I wasn’t really sure how I could contribute and even had nightmares that my contribution could actually derail or even wipeout the whole WordPress open source movement. I needn’t have worried.

WordCamp London 2015 Contributor Day

All contributors were ushered into a large room at the superb London Metropolitan University. We all sat randomly and nonchalantly on tables before Jenny Wong kicked off the proceedings and explained how the day was going to pan out.

WordCamp Contributor DayJenny gave us an overview of the various contribution teams available to us and asked us to choose one. With the help of a team spokesperson we were giving a quick run down of what each group do.

There were many different teams to choose from but I was torn between Accessibility and BuddyPress. I was keen to learn more about and to contribute to both.

Accessibility vs BuddyPress: What team should I choose?

The case for BuddyPress

I have been using WordPress for a long time but have never really used BuddyPress in anger. This could have been a great opportunity for me to learn more about this social networking WordPress plugin. The introduction to BuddyPress was given by Paul Gibbs. I had the pleasure of spending a week with Paul at the WordCamp Lancaster Retreat and he really is a great bloke. Plus he is a Lead Developer on the BuddyPress project.

The case for Accessibility

I had largely forgotten about website accessibility, for many years I thought accessibility was sorted. About ten years ago, I remember a web accessibility ‘expert’ at a conference telling us all that the war on accessibility had been won. The Web Standards movement made websites much more accessible by default. Good, validating, semantic markup was the answer. Super, that’s one less thing to worry about. But I was wrong.

A couple of years ago I had the pleasure of attending the Altitude Web Conference which was pretty cool. For a start Jeremy Keith and Paul Boag were talking, but one man really instilled in me just what a difference well designed inclusive technology can make.

Mobile First Inclusive First

Robin Christopherson showed us how empowering technology can be; when beautifully designed and built to be inclusive from the ground up. He is a big Apple fan boy, because iOS was built to be inclusive from the start. You shouldn’t just try and bolt this on at the end of a project. Robin, who is blind, can even take photos from his iPhone. His battery life is awesome too as he doesn’t need the screen on. His iPhone can even tell him if he has left his lights on after his guests have left. Wouldn’t it be cool to make websites which made the blind see?

We are all temporarily able-bodied

Robin told us is that we are all TABs. That is, we are all temporarily able bodied. Eventually even the best eyes will fail. That tiny, light grey text might look really cool on your web page to you right now with your perfect eyesight, but how will it look when you get older? I have just ordered my first pair of glasses, my eyes are nowhere as good as they were twenty years ago. So, getting to know more about accessibility would be a good idea if nothing else but from my own selfish view point!

Team a11y FTW

In the end Team Accessibility were a little short of numbers, so I put my hand up and joined the Accessibility table. I’m really glad I did, but hope one day to be able to contribute to BuddyPress at a future WordCamp.

Here are my recollections and some easy a11y take aways which I learnt at the table of the WordPress Accessibility Team at WordCamp London:

Hello Team a11y

Fortunately for me I sat next to Rian Rietveld. Rian is a WordPress accessibility expert and regular contributor to the WordPress Accessibility Team. She was very patient and a great teacher and she spent quite a bit of time explaining to me and a couple of other a11y noobies, just how important accessibility is. She pragmatically and carefully explained some of the more important changes we can make to our websites and WordPress themes to make them more accessible. Sitting next to Rian was the equally helpful Gary Jones. Like Rian (and myself), Gary is a Genesis Framework user. So I definitely struck gold by choosing team a11y!

What is accessibility?

Accessibility is often viewed as making your site work on screen readers. In reality, web accessibility is a subset of UX focused on making your websites usable by the widest range of people possible, including those who have disabilities.
MYTH: Accessibility is “blind people”

Accessibility is often abbreviated as the numeronym a11y, where the number 11 refers to the number of letters omitted. This parallels the abbreviations of internationalization and localization as i18n and l10n respectively.
~ Computer accessibility on Wikipedia

You can learn more about Accessibility in the WordPress Theme Handbook.

Never mind the bollocks, your website could be dangerous

As web designers we all know just how important creating effective, functional websites is. Both we and our clients wouldn’t thrive if we didn’t do a good job. This is a huge responsibility. But I never knew that our websites could even cause harm to our visitors. Yes, really! Code should be poetic, not tragic. I’m not been being overly dramatic either:

1. Animations suck

Yes, I know we all love Family Guy, but animations are probably not a good idea for the web. In 1997, a cartoon on television in Japan sent over 700 children to the hospital, including about 500 who had seizures. Seizures can be triggered by flashing visual content. And no, warnings don’t work. Children are likely to ignore them and for many they won’t know if they have a seizure disorder until they actually have one.

2. The title attribute must die!

The title attribute is one of my favourite HTML attributes. So, I was pretty dismayed when Rian told me that apart from a few edge cases, the title tag shouldn’t be used at all! Yes, the title tag must die. Farewell title tag, is was nice while it lasted.

3. Font Awesome, may not be so awesome

I’m a big fan of icon fonts and Font Awesome in particular. Scalable, retina friendly graphical icons, what’s not to love? But used alone, without text to support the meaning of the icon and especially inline is not a good idea. There is not a lot of meaning in this on it’s own:

<i class="fa fa-users"></i>

Sure, people might be able to guess what it is, but what if you can’t even see the icon?

There are of course other ways of using icons like this, in a more inclusive way. I like to think of it as a natural extension to the progressive enhancement school of web design. If you can add styling for people that can actually enjoy it, great. But if not, you’re not doing it right. For example the best icon is a text label.

4. Say, howdy to the Screen Reader Text class

There will be times when you need or want to present visual information to the visually impaired and in a way that is readable by screen readers. Enter the magic of the screen reader class. If you had the pleasure of witnessing Bruce Lawson’s talk at WordCamp London you will know all about the magical browser fairy. Screen readers have their own fairy too, who speaks anything with the special screen-reader-text class. i.e:

<span class="screen-reader-text">The screen reader will ‘speak’ this text.</span>

Here is a way of hiding this class from regular browsers:

Recommended reading: The screen-reader-text class, why and how?

5. Don’t break the back button

Don’t open links in new windows or tabs. We all know this breaks the back button but it can be particularly troublesome for visually impaired visitors. Just don’t do it.

6. Headings rule

Having a good heading structure is very important, not just for semantics or SEO.

They (headings) are the first step most screen reader users take when they begin to navigate your web page. 65.5% of users will start by navigating headings.
~ The Headings Hierarchy Challenge by Joe Dolson

HTML5 allows for multiple H1 headings but it is arguably better to only have one H1 per page, and to structure each page with a clear, sensible and easy to follow heading hierarchy.

7. Don’t auto-play

This is so 1998 and it sucks on so many levels. Yep, don’t let audio, video or anything start playing back automatically on page load.

People using screen-readers navigate by listening, so any sound playing when the page loads will interfere immensely.
~ Never use Auto-play

8. Don’t reinvent the wheel

Don’t make a link do something it’s not supposed to. A button is just a button and an input is just that, a form input field. HTML rocks and by sticking to the correct usage of each element you make the web awesome for everyone especially for accessibility.

9. Use ARIA Roles

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.
~ W3C WAI-ARIA Overview

Adding aria attributes will help screen readers and other machines understand sections of your site, such as navigation elements and forms.

10. Keyboard Accessibility

Folks should be able to access all content using the keyboard alone. You can try this on your own website. Use the tab, tab + shift (to go back) and the enter key. Sighted users must be given a visual indicator of what element currently has keyboard focus.

Keyboard accessibility is one of the most important aspects of disability access. Blind people generally cannot use a mouse because they cannot see where to click. They use their keyboard almost exclusively. Additionally, some individuals with low vision may use a keyboard for improved interactions if the page is enlarged and the contrast is high.
~ Keyboard Accessibility

11. Contrast

Visitors with a visual impairment may prefer higher contrast pages whilst those with reading difficulties may need a lower contrast. Try to strike a reasonable balance and avoid extremes. Whenever possible, use a color contrast tool to check foreground/background contrast ratios across your theme. The minimum contrast ratio that you should aim for is 4.5:1.
~ WordPress Accessibility – Contrasts

Contrast Checker

12. Colour

Julio Potio is colourblind and treated us to a great on colour. My takeaway from this was to give coloured text on a coloured background a check in a colour blindness simulator. In bar charts and pie charts use different patterns or line weights instead of colour alone.

Approximately 10% of all internet users have problems seeing colors, especially those suffering from color blindness…
Whenever possible, use a color blindness simulator to check your design palette and avoid using color alone to distinguish important elements.

~ WordPress Accessibility – Colour

Why embrace accessibility?

How many older or lesser sighted people will simply skip your website because they can’t read it? Can you afford to exclude some groups of people? It’s easy to think; ‘My customers are all able bodied and have good eyesight. My shop is designed for young and highly active skateboarders’.

But what happens when Auntie Flo wants to treat her nephew to a new skateboard for Christmas? Yes, Flo will go, and spend her money somewhere else.

You might spend hours tweaking your design for IE 6/7/8 users, but you are probably better employed focusing your attention on the blind, people suffering with sight loss, the colour blind, the less physically able and the older generation.

In Britain there are approximately 2.7 million colour blind people (about 4.5% of the entire population) according to Colour Blind Awareness. The Royal Institute for the Blind say that almost two million people in the UK live with sight loss. That’s around one person in 30. Of these, around 360,000 people are registered with their local authority as blind or partially sighted.

In Britain alone this is a massive group of 4.7 million people affected by colour blindness and sight issues, add in older people and the physically disabled and this is a significant number.

In November 2014, IE 6/7/8 combined is about 3.7% globally. In most cases people can choose to use another browser, and in time they will update to something more current, but people can’t do much about their eyesight or physical disabilities. It’s not just eye issues that you need to consider. Some can’t use a mouse or trackpad. Many will have to use just the keyboard or an alternative form of input device. Try tabbing though your website. Does it work for you? How many of your users are struggling with a faulty trackpad or mouse?

Just how is that colour blind person going to choose the right coloured t shirt from your store if you just show coloured pictures? That’s easy, you say; I’ll just add the title attribute to the image. No!

This is just the start!

Please be advised that this article is in anyway a comprehensive tutorial in website or WordPress accessibility! I am just starting out on my adventures with #a11y, for instance I haven’t even touched my own website yet!

I do hope you have found it interesting and hopefully inspiring. If you take one thing away from this, start contributing to WordPress. In my short history of contributing I have got much more back than I have given. I hope to readdress this balance overtime. If you get the opportunity to attend a WordCamp Contributor Day, do it. If you would like to learn more about Accessibility and WordPress Accessibility check out the links below.

Make WordPress Accessible

If you are an expert in Accessibility please feel free to comment below if you notice any errors or any of the above needs clarifying! If you are not an expert, please comment anyway!

WordPress Accessibility Plugins

  • WP Accessibility fixes common accessibility issues in your WordPress site.
  • Access Monitor Test your WordPress site for accessibility compliance. Run on-demand tests or schedule a weekly accessibility check.
  • Gravity Forms – WCAG 2.0 form fields Modifies Gravity Forms form fields and improves validation so that forms meet WCAG 2.0 accessibility requirements.
  • Genesis Accessible Fixes some accessibility issues with the Genesis Framework.
  • .screen-reader-text” theme support Supports the upcomming “.screen-reader-text” CSS class. This adds support for those themes that don’t support yet.
  • Accessible Dropdown Menus Makes dropdown menus in many WordPress themes keyboard accessible.
  • Genesis Accessible Dropdown Menu Adds keyboard accessibility to the Genesis menus.

WordPress Accessibility Themes

It’s good to know if you want an accessible WordPress theme many of the recent WordPress themes are accessible by default.

  • Accessible WordPress Themes
  • Leiden (download) an accessible WordPress Theme for the Genesis Framework
  • Utility Pro a commercial accessible theme for the Genesis Framework

Accessibility Resources

  • Accessibility in the WordPress Theme Handbook
  • Web Content Accessibility Guidelines (WCAG) 2.0
  • A11y Code Slides
  • What can I do now for better accessibility?
  • WordPress Themes Plugins and Accessibility Slides
  • Accessibility myths for a mobile generation Slides
  • Four plugins to improve accessibility
  • How to create accessible WordPress themes


Thanks to Rian Rietveld and Gary Jones for making me not feel such a noob and giving me a warm welcome. Also, it would definetely be amiss not to mention Graham Armfield, whom I’ve had the pleasure of seeing giving many talks on accessibility at various UK WordCamps and who gave another great presentation on WordPress Accessibility at WordCamp London 2015. View slides from Graham’s presentation: Themes Plugins and Accessibility.

Beware of Vicious Sid

Vicious Sid
Blind Wapuunk One of the highlights of WordCamp London was Scott Evans and his punk themed and of course . Wapuunk! is a derivative of the open source Wapuu and released under the GPLv2. You can contribute to the Wapuu archives on the official repository.

Some of you may have noticed my take on Wapuu and Wapuunk! Who I have christened Vicious Sid. Sid is a blind punk, a lovely chap actually, but beware his white cane. He has been known to wrap the knuckles of web developers who create unaccessible websites. You have been warned!

Ouch! FFS Sid! Leave it out mate!