Accessibility Resources

Information and Tools

Many people have asked us for accessibility information. Information is readily available from several sources. WebAIM has a wealth of information about accessibility, and the mailing list is especially good. At you will find a list of accessibility checking tools and some info about adding content to WordPress sites in an accessible manner.

Rules of the Road

While Section 508 is often referred to as the rules of the accessibility road in the USA, it is sorely outdated. A 508 refresh is underway. The rest of the world uses the W3C Web Content Accessibility Guidelines version 2.0 (WCAG 2.0). The 508 refresh will bring it into synchronization with WCAG 2.0, so if your orders are to adhere to 508, you’ll be ahead of the curve if you refer to WCAG 2.0. The WordPress accessibility team refers to WCAG 2.0 and we test to level AA. There are some very good resources by the W3C to explain WCAG. But before you look at the guidelines or success criteria there are some principles to keep in mind first.

Understanding the Four Principles of Accessibility: Perceivable, Operable, Understandable, and Robust (POUR)

The following principals are from the WC3 Understanding WCAG 2.0:

The guidelines and Success Criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:

  1. Perceivable – Content is perceivable through sight, hearing, and touch and is transformable in multiple ways. For example, text (sight) can be transformed into audio by using a screen reader (hearing) and into braille using a refreshable braille display (touch).
  2. Operable – User interface components, navigation, and content must be navigable or operable using various input methods like screen readers, voice navigation, braille keyboards or even just your left thumb.
  3. Understandable – Information and the operation of user interface must be understandable by all. Did you declare the language in the doctype statement so screen readers and text-to-speech produce proper pronunciation? Are you explaining jargon and acronyms?
  4. Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. Some people even use a sip and puff tube with alternate interfaces..

Getting Help

Contact us by using the pathways on our Get Involved page.

Accessibility testing of the Twenty Fifteen theme

This week the new theme Twenty Fifteen was placed into trunk, so we could take a look at it.

We discussed the issues found in the replies with @davidakennedy‘s post: Time to Test Twenty Fifteen! and in our testing session last Monday.

Here’s a summary of what we found and the follow up on that (we assigned people to post tickets on this).

The order is in order of priority.

1. Heading structure

To our opinion multiply H1’s are not a good way to set up the heading structure.
Our suggestion:
One H1 per page. This is the site title for the home page, the page of post title for a single page or the archive title for an archive. The rest of the content should be meaningful devided into h2/h3/h4 etc headings.
An improvement that can be easily made is change the H1’s for the widget titles into a H2 in functions.php.
Ticket: @davidakennedy #30065

2. Menus

The main menu works good with keyboard only, also with a submenu.
But with a screen reader it gives problems and the structure isn’t read well.
This may need some study to do it properly
Ticket: @davidakennedy #30083

3. Search form

In the current HTML of the search widget form there is no proper relation between the label and the input field. The input should have an ID and the label a for= to the ID.
Also the submit button has class with display: none; That should be a class screen reader only.
Ticket: @rianrietveld #30110

4. Thumbnail link

The thumbnail of a post in archives are placed inside a link to the post itself.
The alt text is the alt of the image, this can result in a link text that makes no sense.
Screen reader users want to know what’s on the image, but don’t want to lose context on where the link is going.
There are different ways to solve this, as we can see in ticket #15926 and #28861
Maybe finding a solution here could also be a solution for #15926
Ticket: @rianrietveld #30076

5. Sidebar is placed above the content

We decided that that’s ok.
There is a skip to content link for keyboard and screen reader users, that should be sufficient.
The toggle on the sidebar should have a slightly different screen reader support.
Ticket: @bramd

6. Background images next-prev links should be darker

Ticket: @davidakennedy #30069

7. Underline links on hover

Underline menu links and post links in archive on hover to make it more clear they are a link
Ticket: @katherinemancuso #30108

8. Site description

The site description should not be defined as an H2 heading. It is not a section or content title.
We suggest placing it inside a p element.
Ticket: @rianrietveld #30057

9. 404 template Text: “Maybe try one of the links below”.

This may be old text that needs to be updated
Ticket: @davidakennedy #30061

Further commenting and work we will do in the tickets on the trac as they are posted.

This list of issues is not complete. If you find other accessibility issues? Please reply to this or @davidakennedy‘s post: Time to Test Twenty Fifteen!

A big thanks to @davidakennedy, @nsousa, @bramd, @katherinemancuso, @arush, @sharonaustin for testing.


WCSF Final Planning

If you are not attending WCSF this year, you can ignore this post. If you are coming and planning to participate as part of the accessibility team, please click through and read it all. 🙂

Continue reading

#wcsf, #wcsf2014

Accessibility/UI Collaboration on Posts/Pages Screen

There are several tickets open that relate directly to accessibility in the content editing experience on the posts/pages screen (see this post by Joe Dolson for details). Since Avryl is currently working on the editor this is a good time to discuss combining efforts to work on accessibility/UI for the posts/pages screen as well. With combined efforts we could create a revised/improved UI for the posts/pages screen while taking accessibility into account during the entire process.

  • Change the UI to create an intuitive post/page creation experience for the user
  • We can possibly use parts of CEUX for this
  • The UI should be built with a focus on Accessibility first
  • Minimize or eliminate the need for documentation
  • Collaboration with Avryl will ensure that any changes to the editor will be taken into account when creating a new UI.

This was discussed some in the Accessibility meeting on 10/8 (link).  Avryl mentioned she could use some feedback on the inline tools plugin when it’s ready (link).

The kick-off meeting is currently scheduled for UTC Thursday, October 16, 2014 at 8:00 PM.  If anyone would like to be involved in this project, please join us.  I scheduled the meeting time based on best times for UTC to Central US time zone.  Please feel free to comment if you would like to attend but are unable due to the time.

We have the potential to make some very impactful and beneficial changes both in terms of usability and accessibility.

Time to Test Twenty Fifteen!

Today, Twenty Fifteen landed in /trunk.

@iamtakashi and others have worked really hard to make this first pass accessibility-ready from the start. 🙂

I’ve done an initial accessibility-ready review and advised on a few bug fixes. But we still should bang and bend this lovely theme from an accessibility perspective.

Note: This theme has different color schemes, so keep in mind only the default one needs to meet the accessibility checks.

We’d love to find a more elegant solution for the focus styles on the main navigation links.

If you’re not comfortable filing a ticket, just comment here and we’ll consolidate them into feedback on future tickets.

Please post all feedback here. If you are using assistive technology to test Twenty Fifteen, please indicate exactly what software you are using and web browser — including the version number, if possible.

To test Twenty Fifteen:

  1. Install WordPress locally.
  2. Download and install the Beta Tester plugin.
  3. Configure the Beta Tester plugin and update WordPress.
  4. Activate Twenty Fifteen and test to these standards.

October 15, 2014: Updated post with instructions on how to get Twenty Fifteen. Updated with additional feedback instructions.


Accessibility Team Update: October 8, 2014

Here’s our team update for the week:

  • We’re continuing our weekly testing meeting. Be sure you note the time in the sidebar, if you’re interested in participated.
  • We now have the Handbook plugin activated on our site and work has begun to create an Accessibility Handbook. Contact @davidakennedy if you’d like to help.
  • @trishasalas is working on tutorials for the accessibility-ready theme tag.
  • We discussed #29838 and how it might fit into some other work going on in Core.