Don’t Forget to Eat Your Accessibilitables!

Earlier this year I designed and developed a new free theme for WordPress called TextBook. It is intended to be used by people and organizations who have a focus on education. After launching a new theme on WordPress.com, we typically follow it up by submitting it to WordPress.org so it can also be used in the open source world of WordPress. There, a secondary review process happens which sniffs out any issues that may not have been caught during our own internal reviews.

It was during this stage that I learned how much I didn’t really know about accessibility. In particular, I learned navigating a website only using the tab key requires special consideration so screen readers can use the site just as effectively as a mouse-based or touch-based interface. As an example, I’ll use the menu in TextBook which is where the accessibility issues were the most apparent.

TextBook page menu with a mouse:

As you can see, top-level and sub-level menus are perfectly accessible as expected when using a mouse.

TextBook page menu tabbing (bad):

In this example, I’m using the tab key to focus on menu links in the navigation. Notice how a subtle dotted border is added to the clickable elements when they are put in focus by the tab key. This let’s a user know when an element is actionable and they can press “Enter” or “Return” to jump to the link referenced by that in-focus element. However, because the borders are so faint, it isn’t clearly accessible when you compare it to how the menu works when using a mouse. Also the sub-level menus are totally ignored by the tabbing in this example which was actually the crux of this accessibility problem.

TextBook page menu tabbing (good):

In the corrected example above, you’ll notice the sub-menus are fully accessible by simply tabbing through the site (Yay!). Also, the on-focus styles are more obvious and match the mouse behavior a little more closely. To get this to work, I needed to refactor the markup to use the tabindex attribute. It can be used to set an order for tabbable elements so screen readers can browse a page in a specific order defined by the markup.

While I had seen this attribute many times before, I never really considered how it might be useful or when it should be applied. By conditionally adding a tabindex=”0″ or tabindex=”-1″ value to the sub-menu links, I was able to make the browser aware of those sub-menu links and present them in a way that makes them mimic the behavior of the mouse. Previously, those sub-menu links were totally hidden to screen readers.

The main thing I learned from this is accessibility should not be an afterthought. It was quite difficult to retrofit the TextBook menu to account for tabbed browsing at such a late stage in the development process. The original structural logic in the TextBook menu simply was not equipped to handle screen readers, so I needed to refactor the markup, the CSS and the Javascript to get it all to work properly.

At the bare minimum, starting development with accessibility in mind means the sites I work on will have increased reach by including readers who may not be browsing with a mouse or a touch device. The benefits of accessibility are less apparent to the average user but absolutely vital to many not-so-average users. I’m reminded of what it was like being a kid and trying to avoid eating vegetables on my dinner plate because they didn’t provided the same instant satisfaction I got from meats and sweets. After a while though, I ended up loving those vegetables and the unseen benefits greatly outweighed the quick sugar energy burst (and crash) of junk foods. Going forward, accessibility is something I’ll need to start considering from the very beginning of the front-end development process and I think you should too 😉

Some useful resources: