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