Want to participate in reviewing WordPress themes for the accessibility-ready tag? There’s a trac keyword for that! Themes awaiting an accessibility-ready review.
Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts
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: http://make.wordpress.org/docs/2014/02/04/ah-o-update-3-february-2014/
Discussion about testing continued this week with a question about generating tickets to address test findings. We will not pursue creating tickets until we have completed testing all admin screens. Reference was made to outstanding accessibility tickets and how they can be viewed. We will be looking for patterns in addition to specific issues. An example of this is an early finding that effective visual focus indication for keyboard-only users is inconsistent. This is a general pattern, not limited to any one screen.
The accessibility team discussed team leads and the consensus of the group is that Joseph Karr O’Connor @accessiblejoe will remain as the team rep and the very capable Amanda Rush @arush will step up as the alternate team rep.
Ticket Activity Report
@grahamarmfield reported progress on ticket 26602: Insufficient information for screen readers in themes.php. “On the new Themes page in trunk, it is now possible to tab to each of the themes within the list of themes found. However for screen readers there may be no audible feedback to tell the user which theme has focus.” Thanks to @joedolson for the initial patch and everyone else who worked on the solution. The status is now: closed defect (bug) (fixed).
Some of us are proceeding with the keyboard functionality audit of all the admin screens. We have a target deadline of February 5, 2014 to complete the testing. There is a learning curve as each team member learns the routines. Some of us have never done testing so this is a valuable learning experience for us. We are comparing our findings before making them public. @rianrietveld has made a test instance available to us so that we are all using the same environment. She also posted about this on our WordPress Accessibility LinkedIn group. Thanks to everyone who is participating.
Testing 3.8 Admin Screens
The team discussed our current project, keyboard testing of 3.8 admin screens. There is now a new page on Make WordPress Accessible named Testing, and a sub-page under that named 3.8 Admin Screens Results. The testing page contains a list of 3.8 admin screens and a sample results table. The results page contains the report we are starting to build. We agreed on a testing methodology and the WCAG 2.0 AA success criteria we will reference. Testing is now underway.
- During the meeting @jorbin notified us that #26602 is ready for testing after he applied a patch.
- Also @davidakennedy is still committed to helping out the Widgets project and @grahamarmfield is going to have a look at the AH-O2 plugin which is now on the repo.
- At the same time we are checking the admin screens for keyboard accessibility we will also be doing a separate report on all WCAG 2.0 AA issues on the P2 Theme we are using for this blog.
In 1982, in his Frank and Ernest comic strip, Bob Thaves wrote about Fred Astaire: “Sure he was great, but don’t forget that Ginger Rogers did everything he did, backwards…and in high heels.”
Doing the accessibility dance is very much like that. Great care is taken to make sure that not only do we produce useful reports and code solutions but that whatever we create is as accessible as possible. For instance, last week we stated that when we produce word processing documents, they will be output as RTF, to preserve formatting between platforms. We also said we’d use Dropbox because it integrates so tightly with operating systems, giving our team access to files while using assistive technology in familiar ways. Using Dropbox as a staging area for documentation and automatically pushing finished work, including code solutions, to Github seemed like a good way to make our work public. The good is often the enemy of the best.
This week we discussed this blog and how we can best integrate our workflow into the WordPress environment. Remember when Drupal set up a WordPress blog to publish info about Drupal? Perhaps we should explore our workflow options within our own ecosystem. This week we started working through the issues we face when contemplating using WordPress to publish our findings.
Mostly all of the accessibility assessments I’ve worked with, both manual and automatic, contain tables to display issues, reference to guidelines, solutions, etc. It might not be absolutely necessary to display this info in tables, but tables sure help to organize this type of tabular data. We just need to code accessible tables in WordPress. You can read how to properly code tables in Creating Accessible Tables by WebAIM.
TinyMCE and Tables
WordPress ships with a WYSIWYG editor, TinyMCE. TinyMCE has a table tool. The TinyMCE site does have a page devoted to TinyMCE accessibility with one brief reference to tables. We’d have to test both the back end functionality and the output of that tool before we can say that it can be easily used with a keyboard and that it outputs accessible table code. If we need to, we’ll work with the Meta team to devise an accessible table feature for TinyMCE and it will benefit more than our project.
This page is produced using the P2 Theme. When it comes down to it, if we really want to make sure that our output is accessible, then we should check the P2 Theme for accessibility. This also will benefit more than our project alone.
At the end of the meeting we summed up our next actions to work within WordPress to publish our accessibility findings accessibly, and to proceed with our focus on keyboard accessibility of admin pages:
- Check TinyMCE table tool function and output, work with the Meta team if needed
- Check P2 Theme for accessibility
- Proceed with keyboard functionality assessment of admin pages
Happy New Year to the entire WordPress community!
Accessible IRC Clients
Thanks to the team members who joined us today, and to @grahamarmfield who reported in while traveling. Just as we got underway we had a question on Twitter asking which IRC clients are accessible plus we found out later that one of our team members, @arush was sidelined when her IRC client “totally choked.” So after the meeting we used the LazyWeb technique and asked @WPAccessibility followers for some suggestions:
- For Windows, Jennifer Sutton @jsutt suggests Instantbird
- For Mac, @jsutt also recommends Adium
- For Unix, Chris Nestrud @IAmChrisN recommends irssi
Much thanks to Jennifer, who is a big help to the accessibility team and to the entire accessibility community, and also thanks to Chris Nestrud for the Unix suggestion. Chris says: “anything with a text UI on Unix should work. I like irssi.” We can still use suggestions for accessible IRC clients for iOS, Android, and Windows Mobile.
We are starting the process of auditing 3.8 for keyboard accessibility. Reports are generated in the process of accessibility auditing. We discussed how to handle those reports. A few meetings ago @ceo suggested that we create the reports in RTF format so the formatting is not lost in the platform shuffle and we will do that.
During today’s meeting we finalized plans to create a public Github repository where we will store the finished reports and other documents as we produce them. We will also create and update our assignments and to-do lists on Github.
We also finalized plans to create a Dropbox account for the team which we will use to store documents to be reviewed before they are finalized. Tom Harrigan made the suggestion that we set up a directory in Dropbox that will automatically sync from dropbox to github.
@davidakennedy has agreed to set up Github and Dropbox. Thanks David!
Focus on Keyboard Accessibility
The accessibility team met today to discuss a new initiative:
- We will conduct an audit of keyboard accessibility and make those findings available to everyone
- We will reach out to other teams to disseminate this information
- Our short term goal is to add keyboard accessibility to everyone’s toolkit
- Our long term goal is to institutionalize accessibility.
Two projects have asked for help from the accessibility team:
Can anyone in the group take a look at the issues raised in this forum thread?
I’ve created all new tickets for each file referenced from the original remove title attributes trac ticket (http://core.trac.wordpress.org/ticket/24766). I originally split it up into 17 separate tickets, but closed 3 of them already, because they had already been committed into 3.8 or earlier.
I’ve added comments and/or patches, as relevant, on all of the remaining tickets – so please chime in with opinions as relevant! Many of these incorporate situations where a 2nd opinion would be valuable, because the title attribute incorporates relevant information and some alternative handling may be necessary.
http://core.trac.wordpress.org/ticket/26549 – 2nd opinion
http://core.trac.wordpress.org/ticket/26550 – 2nd opinion
http://core.trac.wordpress.org/ticket/26551 – 2nd opinion
http://core.trac.wordpress.org/ticket/26552 – 2nd opinion
http://core.trac.wordpress.org/ticket/26553 – 2nd opinion
http://core.trac.wordpress.org/ticket/26555 – 2nd opinion
http://core.trac.wordpress.org/ticket/26558 – 2nd opinion