WordPress Accessible Themes Roadmap

Initial Proposed Timeline

What When
Initial content (3 initial steps) December 12 2014 Published Dec. 15, 2014
All resource copy written Late January 2015
Code library finished Note April 2015
All accessibility info published in various locations (See below) April 2015
All new themes to automatically be tested for accessibility November 2015

Brainstorm of Content Types

We felt that the following pieces of information should be provided for theme dev (and others) to help them understand the reasons why accessibility is so important, and how to actually go about bringing accessibility techniques into themes.

  • The 3 steps – the top 3 things to do to improve accessibility within a website. These are:
    • Keyboard navigation
    • Controls that aren’t controls
    • Unidentified images
  • A resources page – “A  way in”
  • The WordPress Accessibility Guidelines – what WordPress defines as being accessible
  • A world map of accessibility legislation
  • Landing pages
    • on Make WordPress Accessibility (make.wordpress.org/accessibility)
    • on WordPress main site (wordpress.org/accessibility)
  • Why accessibility is important – prose + video
  • How to do accessibility – prose + video
  • Pattern library
    • best practices prose – explaining what and why
    • code snippets – examples that you can use
  • Examples of attractive accessible themes
  • How to make your themes accessible
  • How to test that your theme is accessible
  • A list of gotchas for plugins (perhaps an impostor from another page)

Other potential accessibility reference sections – but not specifically theme related:

  • Guide for writing content in an accessible way

Stimulating Phrases

During our sessions we came up with a series of phrases that were worth capturing as they can stimulate work in different directions and underpin our ethos:

  • Take the onus off the user – A user of a WordPress theme should not have to worry about the accessibility of the theme.
  • Accessibility is coming, it is not going away.
  • Checking all themes for accessibility
  • WordPress will be accessible by default
  • An opt-out for theme authors, but themes flagged as not tested
  • This theme has not been checked for accessibility
  • This theme was approved before WP a11y guidelines were published
  • What’s our theme tagging strategy
  • Accessible icons for themes
  • Automated testing vs manual testing
  • The bonus of SEO from doing accessibility
  • Check the accessibility of the underscores theme and Bones
  • Dispel the myths about accessibility
  • An aggressive timeline
  • An outreach programme

Places that need links to accessibility resources

  • Make WordPress Accessible
  • WordPress.org Accessibility
  • Theme Handbook
  • Developer Handbook
  • Theme upload page
  • Training team page(s)

That’s “finished” for a given value of finished. Return

Digital Accessibility Centre Visit – Part 3: The Blind Perspective

This is the third post documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan BamberThe first post can be found here, and the second post here.

Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

In this post we take feedback from Carly who is totally blind. She showed us how she used a screen reader and gave us some great feedback on using the WordPress admin screens with a screen reader.

Continue reading

#accessibility, #assistive-technology, #feedback, #jaws-admin, #screen-reader, #testing, #trac-2

Digital Accessibility Centre Visit – Part 2: Poor Vision

This is the second post (of three) documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan Bamber. The first post can be found here.

Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

In this post we take feedback from Gary who has poor vision.

Continue reading

#accessibility, #colour-contrast, #feedback, #testing, #text-resize

Digital Accessibility Centre Visit – Part 1: Introduction, Keyboard and Dragon Testing

On February 25th 2014 I was honoured to visit the offices of the Digital Accessibility Centre in Neath, South Wales, UK. The trip was organised by fellow wpa11y team member Siobhan Bamber.

This post is the first in a series of three which summarise the feedback we received on using WordPress from three users with impairments. Our first session was with Becs who uses Dragon NaturallySpeaking (voice recognition software) and does keyboard accessibility testing.

 

Continue reading

#accessibility, #assistive-technology, #feedback, #keyboard, #voice-recognition

AH-O2 Accessibility Testing

I’ve been doing some accessibility testing with version 0.4.0 of the AH-O2 plugin which adds tooltips to some links and input fields within the admin area where it’s felt appropriate.

I’ve commented on my findings directly into the Docs blog. You can see my comments here: https://make.wordpress.org/docs/2014/02/04/ah-o-update-3-february-2014/

#ah-o2, #help, #testing

Patches provided for #25459 – Meaningful links in Admin

I’ve added two patches to trac ticket #25459 which solve the meaningful links issue. They use a new function which employs the aria-hidden attribute to allow meaningful text for screen readers to sit alongside shorter text for sighted users, and allows both strings to be translated with correct grammar/spelling in all languages.

They work for me, but it would be great if someone else could test them on their own environment with a screen reader to double check. Maybe we could get this into 3.8.

#a11y, #accessibility, #aria-hidden, #i18n, #trac-2

Analysis of what gets into the alt and title attributes when adding an image into a page/post

There was some debate in last night’s IRC chat about trac ticket 26270 raised by @yaelkmiller. Her original point was that when adding images to pages and posts, the Alt text box should have more prominence than the Title box – the alt attribute being an important accessibility feature.

Personally, I think the idea is a good one, but discussion and comments by @helen also revealed some interesting behaviour when inserting images concerning what text ends up in the title attribute of the image, and what text ends up in the alt attribute.

I’ve done a series of tests using different use cases and they are presented in the tables below – including my expected results and the actual results.

Uploading images

Test No. Use Case Graham’s Expected Result Actual Result in Page
1 Upload image, add it to page with no change to Title box or Alt text box Title attribute set to image name minus suffix Title attribute absent, alt attribute set to image name minus suffix – ie what the Title box was set to
2 Upload image, add it to page but change Title box, not Alt text box Title attribute set to amended value Title attribute absent, alt attribute set to amended Title box value
3 Upload image, add it to page but change Alt text box, not Title box Title attribute set to image name minus suffix, alt attribute set to amended value Title attribute absent, alt attribute set to amended Alt text box value
4 Upload image, add it to page but change both Alt text box and Title box Both title and alt attributes set to amended values Title attribute absent, alt attribute set to amended Alt text box value

Using images from media library (previously uploaded) without amendment

Test No. Use Case Graham’s Expected Result Actual Result in Page
5 Add image from media library that has Title box set but not Alt text box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was before
6 Add image from media library that has Alt text box set but not Title box Alt attribute set but not title Alt attribute set but not title
7 Add image from media library that has both Title box and Alt text box set Both attrubutes set Title attribute absent, alt attribute set to whatever Alt text box was before
8 Add image from media library that has neither Title box nor Alt text box set Title attribute absent, alt attribute empty Title attribute absent, alt attribute empty

Using images from media library (previously uploaded) but making amendments

Test No. Use Case Graham’s Expected Result Actual Result in Page
9 Add image from media library, that has just Title box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
10 Add image from media library, that has just Alt text box set, update Alt text box Alt attribute set but not title Title attribute absent, alt attribute set to whatever Alt text box was amended to
11 Add image from media library, that has neither Title box set nor Alt text box set, update Title box Title attribute set but not alt Title attribute absent, alt attribute set to whatever Title box was amended to
12 Add image from media library, that has neither Title box set nor Alt text box set, update Alt text box Alt attribute set, no title attribute Title attribute absent, alt attribute set to whatever Alt text box was amended to
13 Add image from media library, that has both Title box and Alt text box set, update Alt text box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was amended to
14 Add image from media library, that has both Title box and Alt text box set, update Title box Both attributes set Title attribute absent, alt attribute set to whatever Alt text box was originally set to

Looking at the results

Using the Add Media Panel to insert an imageThe first revealing thing about these tests is that my own view of how I thought WordPress worked is at odds with the actual results in most cases.

The second thing that’s become obvious is that it’s actually impossible to set the title attribute for an image whilst using the Add Media panel. The title attribute never appears in any of the results.

Actually the only way to set a title attribute image within pages and posts is to use the older image edit dialogue box once the image is placed within the page (or to manually update the HTML obviously).

I think the confusion comes from the labeling of the Title input field in the Add Media Panel. Helen refers to this in her comments on the trac ticket I believe. Maybe to avoid confusion this box should be given another label – ‘Image name’ maybe. I confess that I hadn’t noticed this change in WordPress behaviour – it did used to be possible to directly influence the title attribute of an image when uploading and adding it to a page/post.

I’m sure that I’m not the only one who didn’t appreciate this situation. There is a plugin called Shutter Reloaded that I’ve seen on a couple of sites, which uses the title attribute from the image to provide a caption beneath the image when the full size is shown. Obviously this plugin is broken if site admins don’t realise the title attributes aren’t being written into the <img> tags – and the plugin author perhaps doesn’t realise either. I can’t comment on other lightbox plugins.

What do you think? Is this what you expected? Is this the right way to go?

#images, #media-manager, #testing

Welcome to the Make WordPress Accessible Team

Hello. You’ve found the blog of the Make WordPress Accessible team – a bunch of volunteers who are striving to improve the accessibility of WordPress. We need your help.

Continue reading

#accessibility, #feedback

Accessibility Objectives for WordPress – Initial Thoughts

Some of us have been talking recently about pulling together some accessibility objectives for WordPress. These are things that we feel could, or should, be happening to ensure that the profile of accessibility is enhanced with the WordPress community.

Ultimately, in order to support Matt Mullenweg’s view on the democratisation of the web by web-related software we want as many WordPress websites as possible to be accessible to as many people as possible. We also need to ensure that the WordPress admin screens are not excluding certain user groups from key parts of functionality.

With that in mind, here is our initial list of objectives. Please feel free to comment on these, and to suggest others that you think are also important.

Continue reading

#accessibility

Accessibility IRC Chat – 3rd April 2013

A few of us took part in the IRC chat yesterday (see transcript here). Not surprisingly the main subject was the Add Media Panel accessibility, and the format of the chat turned into a live screen reader test on the functionality performed by @_Redd and @arush (and myself).

@lessbloat had kindly had a go at implementing my quick and dirty pragmatic ARIA solution – for which we are truly grateful. Once we’d got access to an environment where the changes were in effect we could see that vast improvements had been made to the accessibility.

I’ll save the detail to the blog post about Add Media Panel but to summarise:

  • Keyboard-only users can now tab through the items in the media list and select/deselect using Enter key
  • Screen reader users were getting some useful information but possibly only the newest versions can fully use this functionality.
  • Voice recognition users can at least use the tab commands to move around the list and select them.

The key decision now is whether the functionality is useful and solid enough to include in 3.6. A couple of extra enhancements would make the solution better for screen reader users – once again see previous post.

My vote would be to run with it if we can get the small further enhancements. We can hopefully address the rest of the accessibility issues within 3.7.  But what do you think?

#accessibility, #add-media, #irc, #keyboard, #media-manager, #screen-reader, #testing