Looking back on 2015 and forward to 2016

Last year I changed the focus of my company. I wanted to do web accessibility related work only. The plan was to:

  • build and maintain accessible websites only
  • give accessibility training to web developers and graphic designers
  • help developers and companies fixing accessibility issues
  • give talks on WordCamps and Meetups
  • keep contributing to WordPress

So, what became of my plans?

Accessible websites only

This year I build game-accessibility.com, doofblind.nl and rebuild oogvereniging.nl. All accessible and oogvereniging.nl is officially certified WCAG 2 AA by the Dutch Accessibility Foundation.

Homepage website game accessibility

But to keep the wolf from the door, I needed more work. Therefore I’ve build several websites as accessible as possible, but had to make (sometimes huge) concessions to meet the customers wishes. No I’m not listing them here.

Web accessibility training

The developers of Yoast, Yard Internet and Geev all got a training. That was so much fun to do. It strengthens me in the opinion that developers and designers do care account accessibility, they just don’t have a clue what’s important. Letting Apple VoiceOver read their website out loud, is always a good eye opener and a way to create awareness.

Fix accessibility

CopyBlogger asked Graham Armfield and me to improve the accessibility of the Genesis Framework. We set as standard: Genesis and the Sample Theme needs to be WCAG 2 AA accessible. Graham did an audit and I made the code fixes, with the help of many other Genesis developers. In August Genesis 2.2 and a new Sample Theme were released with all the necessary  a11y changes.

Contributing to WordPress

Last year Andrea Fercia joined the accessibility team. His extensive work on WordPress core gave us a big boost. He asked for testers with different assistive technology and we assembled a team of 75 volunteers who regular test WordPress on a11y issues. For this work Andrea and I got recent rockstar credits for the 4.3 release, Andrea became a core committer, and even Matt Mullenweg knows our names apparently. The team grew and works well now.

Ryan D. Sullivan from WP Site Care was very generous and payed for Andrea’s and my trip to WordCamp US in Philadelphia, where we attended the Community Summit with the rest of the accessibility team.


We wrote the accessibility code standards for WordPress core and got the support of several core developers. This means that everything that gets into WordPress core, needs to be WCAG 2 AA accessible. A result I’m really proud of.

Furthermore, this year I gave talks at:

Lessons learned

For a new website I will only work with a project / content manager I trust and a web designer that knows accessibility or wants to be trained to be one.

Never ever let a graphic designer do wireframes or take decisions with the client without me, because this results in me struggling to code stuff I strongly disagree with.

Maintaining over 30 WordPress websites (and discussing stuff with 30 website owners) is too much noise in my head. I need to consider handing over the maintenance of some websites to other WordPress agencies.

Make more time to maintain and give support for the plugin Genesis Accessible. This takes up more time than I thought, therefore I need to include it’s support and development into my weekly routine.

Plans for next year

Focus even more what I really like to do:

  1. Train and educate WordPress developers with the WPDC
  2. Code accessible websites with a good project manager
  3. Maintain the plugin Genesis Accessible
  4. Be part of the WordPress accessibility team
  5. Give talks on WordCamps and Meetups
  6. Finish my book on accessible theme development with Genesis
  7. And study my ass of… duh…

The website oogvereniging.nl is expanding and growing. I love to work on this site, so I will keep doing this. I will look at my other websites and decide this year which ones I keep and which ones I will hand over to other agencies.

The need for accessible websites is increasing in the Netherlands, so this year I plan to do accessible sites with a project manager I know and trust.

The work on Genesis Accessible and the WordPress accessibility team will also stay an important part of my work. It costs time but it’s fun, necessary and good for my PR. Just like giving talks on WordCamps and Meetups and writing a book. Let’s see if I can find the courage of speaking at WordCamp US this year, need to think about that.

Last year has been a good year. I hope 2016 will bring me even further on the path I decided to take: let’s get WordPress accessible and make money on the way.

Happy New Year everyone!

Girls can’t code and my English sucks

Last week I had the exact same conversation four times. With four different WordPress developers. All women.

The topic: I want to publish code, discuss issues that matter, ask questions to core developers, blog, make some noise, contribute, but I’m to afraid to do that. It reminded me of myself.

What is the matter with us women? Why the self inflicted self pity and lack of confidence?

“I am not good enough, I don’t know enough, what if they think I’m stupid, my English really sucks.”

Do only female WordPress programmers think that way? Or are women and men with talent and knowledge all over the world hiding themselves, because they think they aren’t good enough? Sobbing under their desks, anxiously staring at the world, hiding from critisim and ridicule. What a waste of talent and possibilities!

So what are we afraid of, why sell we ourselves short?

Every contribution, blog post, piece of code you publish is valuable. Criticism is part of the job, learn from it, don’t hide, embrace it, it helps you getting better! Nobody makes fun of you when you want to contribute and do you best. You are most welcome!

Do you really think all the guys, that make so much noise, always write perfect code and never make mistakes? Hell no, just like you they work and learn, make mistakes, write bugs and try to improve themselves.

Exactly the same as you…

So girl: pull yourself together, put your teeth into it, jump in at the deep end. Study hard and publish what you found useful. Respect is not earned by sitting silently in a corner.

Show what you can do and be proud of yourself, and don’t be afraid to make a mistake. We are all human, boys and girls alike.

Fix the accessibility of your Genesis responsive menu

The Genesis Framework is my favorite tool to build a WordPress website. And with the next update (version 2.2) a lot of accessibility features and fixes will be added. But a framework is no child theme.
The HTML5 themes you can purchase with StudioPress have a beautiful responsive menu for the primary navigation. And that menu is completely inaccessible for keyboard and screen reader users.

What’s wrong?

The HTML code to show the responsive menu is:

 <div class="responsive-menu-icon"></div>

A div is not focusable, if you tab though a page the menu is skipped and you have no way to open it, only by using a mouse. And also the div is an empty container, with no content.

What needs to be changed?

  1. Change the <div> to a <button>, a button is focusable and clickable
  2. Add some text inside the  <button></button> to tell a screen reader user what the button is about. You can make this visibly hidden by using the screen-reader-text class
  3. Tell a screen reader user if the menu is open or closed by adding dynamically aria-expanded=”false” or aria-expanded=”true”

How can you do that?

The Genesis child themes use js/responsive-menu.js (GitHub) to show the responsive menu.
Change this JavaScript into for example:

jQuery(function( $ ){

 $(".nav-primary .genesis-nav-menu").addClass("responsive-menu").before('<button class="responsive-menu-icon" aria-expanded="false"><span class="screen-reader-text">Menu</span></button>');

 var _this = $( this );
 _this.attr( 'aria-expanded', _this.attr( 'aria-expanded' ) === 'false' ? 'true' : 'false' );
 $(this).next("header .genesis-nav-menu, .nav-primary .genesis-nav-menu").slideToggle();

 if(window.innerWidth > 768) {
 $("header .genesis-nav-menu, .nav-primary .genesis-nav-menu, nav .sub-menu").removeAttr("style");
 $(".responsive-menu > .menu-item").removeClass("menu-open");

 $(".responsive-menu > .menu-item").click(function(event){
 if (event.target !== this)
 $(this).find(".sub-menu:first").slideToggle(function() {


See an other accessible example of an Accessible Genesis responsive-menu.js at GitHub. With the visual text “Menu” (I hate hamburgers) and a leading heading.

You have to add the screen-reader-text class and maybe change the CSS .responsive-menu-icon to style the button so it fits your theme.

So: by changing a few lines of JavaScript and adding a few lines of CSS you turn your responsive menu into a perfectly accessible awesome responsive menu.


Yes, this is a quick and dirty fix. There’s now untranslatable hardcoded text in the JavaScript, this could be done way better and cleaner. But you’ve got the picture of what needs to be changed. If you are a JavaScript pro: all help is welcome🙂

The screen-reader-text class, why and how?

Imagine you are blind, how do you understand a website? You would use a screen reader. All the text in a website is read out loud for you, from top to bottom. To navigate a site you can call a link list and a headings list.

The headings list you can use to navigate inside the page. Jump to a heading of interest and read from there. With the link list you can choose where to go next. There are more ways to navigate a site, but links and headings are most commonly used by screen reader users.

How can you decide where to go, when a lot of the links in a page are called “Read more”. Read more about what?

So, if you are a web developer, how can you help your blind visitor to understand your website? First of all: use headings that make sense. And second: use link texts that tell where they are linking to. And here the screen reader text comes in: it hides text from screen, but not from a screen reader.

For example links with the text “Read more”, “Continue reading” or a plain “>” or a font awesome icon. Looks neat and small and is incomprehensible for your blind visitor. But writing the whole post title in the read more link is long and ugly.

How to fix the “Read more” link?

Say you have the HTML:

<a href="url-here">Read more</a>

You can change this into:

<a href="url-here">Read more<span class="screen-reader-text"> about cute kittens</span></a>

For WordPress for example:

<a href="<?php the_permalink(); ?>">Read more<span class="screen-reader-text"> about <?php the_title();?></span></a>

And then you add the CSS in your stylesheet:

/* Text meant only for screen readers. */
.screen-reader-text {
    clip: rect(1px, 1px, 1px, 1px);
    position: absolute !important;
    height: 1px;
    width: 1px;
    overflow: hidden;

The element with the class screen-reader-text is made very small with clip, which needs the position absolute. Not visible for the eye, but read out load by a screen reader.

Don’t use display: none; or visibility: hidden. Screen readers don’t speak those, so that’s no use in this case.

Font awesome and other icons

How about your social media icons:

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

It’s just an empty container and the <i> has a semantic meaning: text in an “alternate voice”.

Better use:

<span class="fa fa-twitter"></span><span class="screen-reader-text">Twitter</span>

By the way: You can help changing this inaccessible way of implementing Font Awesome by joining the discussion in the Font Awesome GitHub.

Richard Senior did an excellent write up about WordPress, Font Awesome and Accessibility.

Labels in forms

A form input field needs a label. It’s just good practice and it tells a screen reader user what to fill out. A placeholder is no label, screen readers don’t read them well. But a label takes up space and maybe you don’t want that in your theme. So hide it with screen-reader-text.
For example in the WordPress search form:

<form role=”search” method=”get” class=”search-form” action=”url-here”>
<label for=”search-id” class=”screen-reader-text” >Search this website…</label>
<input name=”search” type=”text” value=”” placeholder=”Search this website…” id=”search-id”>
<input type=”submit”  value=”Search”>

Hiding links

As a service to screen reader users and keyboard only users you can add skip links at the top of a page. That way a visitor can quickly jump to e.g. the content, without having to tab though the navigation.

They look something like this:

<ul class="skip-link">
 <li><a href="#nav" class="screen-reader-text">Jump to main navigation</a></li>
 <li><a href="#content" class="screen-reader-text">Jump to content</a></li>
 <li><a href="#footer" class="screen-reader-text">Jump to footer</a></li>

Some JavaScript is necessary to make skip links work properly.

If a visitor can see, it’s nice if the skip links are visible when they come in focus while tabbing though the links. So you can add the CSS to do that:

.screen-reader-text:focus {
    clip: auto !important;
    display: block;
    height: auto;
    width: auto;
    z-index: 100000; /* Above WP toolbar. */

The screen reader text in more detail

Clip versus absolute positioning

.screen-reader-text {
    position: absolute !important;
    left: -999em;

This technique is pretty solid and works in all browsers however there are two main issues with this technique – its relatively easy to break, and it can cause a page “jump” if applied to focusable elements (like skip links and read more links), which can be very confusing to sighted keyboard users. [Reference:  Jeff Burnz and Jonathan Snook]

Different ways of doing it

Gary Jones collected a few different ways of hiding text with clip. And there are more variations. Pick the one that suits your theme or adjust it to your needs.

What about:

clip: rect(1px, 1px, 1px, 1px);


clip: rect(0, 0, 0, 0);

I couldn’t find a specific reason to use 0 or 1px, they both seem valid.

Back and forward compatibility

Clip is deprecated in CSS3, but supported by most browsers, it’s replaced by clip-path. Internet Explorer below version 8 doesn’t want a comma as separator and up to version 11 it doesn’t support clip-path yet, so you end up with:

clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
clip-path: polygon(0px 0px, 0px 0px,0px 0px, 0px 0px);

The other way around: hide from a screen reader

The other way around is also possible. If you have an element that’s not relevant for screen reader users, you can hide it by adding aria-hidden=”true“.
This is used for example in the WordPress Admin for hiding a separator in the main menu.

<li class="wp-not-current-submenu wp-menu-separator" aria-hidden="true">

ARIA roles (Accessible Rich Internet Applications) are instructions for screen readers you can add to your HTML.

WordPress and the screen-reader-text

The name of the class is up to you, but “screen-reader-text” is the standard name for WordPress, and is used by WordPress core in the Admin and the front end and in the bundled themes like Twenty Fifteen. As from version 4.2 this class is WordPress generated CSS, so it’s important that you add it to your theme before updating to WordPress 4.2.

The screen-reader-text wil be used for the get_search_form, the comments_popup_link, the archives and categories dropdown widgets and will be used in more cases in future releases.

If you are a WordPress developer and want more controle over this, please support Gary Jones by commenting on his ticket add_theme_support( ‘screen-reader-text’ ).


And if you can’t add the screen-reader-text class yourself to a WordPress theme: there’s a plugin for that.

Read more screen reader text: I knew you would check

  1. Hiding content for accessibility by Jonathan Snook
  2. CSS in Action: Invisible Content Just for Screen Reader Users on WebAIM
  3. Hiding text for screen readers with WordPress Core by Joe Dolson
  4. Clip Your Hidden Content For Better Accessibility by Thierry Koblentz
  5. Understanding the CSS Clip Property by Hugo Giraudel
  6. Using CSS clip as an Accessible Method of Hiding Content in Drupal, by Jeff Burnz
  7. WordPress plugin “.screen-reader-text” theme support by Jaime Martinez

Photo Read More tattoo: Cory Doctorow.

How I Stopped Worrying and Learned to Love the WordPress Community

WordPress and Accessibility. It has always been a difficult discussion. The developers wrote code, without knowing what’s important for someone that doesn’t see a website like they do. And the WordPress Accessibility team could not find the time or voice to help them fix the problems. So we asked members of the WordPress community for help, and they answered!

WordPress and Accessibility. It has always been a difficult discussion. The developers wrote code, without knowing what’s important for someone that doesn’t see a website like they do. And the WordPress Accessibility team could not find the time or voice to help them fix the problems. So we asked members of the WordPress community for help, and they answered!

Continue reading “How I Stopped Worrying and Learned to Love the WordPress Community”

HTML5 Headings in WordPress: A11y versus SEO?

How to get a WordPress developer all emotional and fanatic: discuss about heading structure.
Here’s my point of view on how headings should be set up in a WordPress theme.
And an overview of the pros and cons brought up in discussions.

How to get a WordPress developer all emotional and fanatic: discuss about heading structure.

Here’s my point of view on how headings should be set up in a WordPress theme. And an overview of the pros and cons brought up in discussions.

Continue reading “HTML5 Headings in WordPress: A11y versus SEO?”

Storytelling in HTML: practical accessibility

A web page can be perfectly WCAG 2 proof, but if it doens’t tell a story, it’s still a puzzle for people that depend on a braille line or a screen reader.
Set yourself in the place of someone who get’s your web page read out loud linearly and the only clue she has on what the structure is, are headings and links.

For my work I build sites for blind people. They use a braille line and screen reader to read and navigate a website. During the development of those websites I learned that blind people read a web page differently than I do.

Blind web users read a page linearly and depend on headings and links to navigate.

This changed the way I build site dramatically, I changed from visual coding to story telling coding. Continue reading “Storytelling in HTML: practical accessibility”

A placeholder is no label; search forms in WordPress can do better

Wordpress developers can do better when building search forms. If it looks OK for me, it works OK for everyone? That point of view only counts when you can see properly. So how to do a search form for WordPress?

WordPress developers can do better when building search forms. If it looks OK for me, it works OK for everyone? That point of view only counts when you can see properly.

Continue reading “A placeholder is no label; search forms in WordPress can do better”