Monthly Archives: May 2014

Joseph Karr O'Connor 8:53 pm on May 8, 2014  

Accessibility Team Update: May 7, 2014

Global AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Awareness Day

I will be talking about WordPress accessibility here in Santa Monica at Yahoo! to celebrate Global Accessibility Awareness Day (GAAD) on May 15. There are many events happening all over the world, perhaps there’s one close to you. If you want to celebrate GAAD but don’t have an event nearby, then here’s a suggestion from Deborah Edwards-Onoro, a front-end WordPress web developer and user experience pro: use only your keyboard for navigation for one hour.

Automated Accessibility Testing

It is necessary for me to point out that the very best enterprise-strength automated accessibility checking environments can only accurately report out about thirty percent of the errors. Nonetheless, automated testing, especially command-line testing, will be a valuable addition to the test environment, and we need to explore this. The Netherlands has a commitment to making sure that government sites are accessible, so they are supporting the development of Quail an open-source, MIT-licensed suite of tests that assess web page structure and content. The library is currently developed against WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. and Section 508 accessibility standards. Accessibility team member David A. Kennedy wrote a great post, “WordPress needs automated accessibility testing” in which he mentions Quail and another tool, pa11y, and I recommend reading what he has to say on the topic.Thanks to David for creating a discussion on this vital topic. David was interviewed by WP Tavern this week and we look forward to seeing that posted soon.

Tenon

Karl Groves, another accessibility team member, is working on tenon.io, which is in betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. now and promises to be a very powerful accessibility checking tool. While Tenon will be proprietary, Karl tells me that: “We are going to have a Free for Open SourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. program. As long as the project using Tenon is open source, the account is free.”

Collaboration

While there is no doubt that the accessibility team can and must improve collaboration with other WordPress teams, we are also interested in creating ways to expand our reach through innovation and also by collaboration with people doing similar work outside of WordPress. Automated testing is one way to innovate. We saw that the Quail project has created an accessibility module to work within Drupal so we invited Mike Gifford, a Drupal 8 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Accessibility Maintainer, to our meeting this week to learn about the Drupal accessibility operation. According to Mike “Just to be clear about the automated (accessibility) testing & Drupal. It will be a great addition in the future, it’s found some interesting bugs when we have applied it, but it really has only been marginally useful thus far.” Mike agreed to share info and join forces with us where our interests are similar and we look forward to collaborating with his team and with accessibility teams for other projects.

David A. Kennedy 6:11 am on May 2, 2014
Tags:   

WordPress needs automated accessibility testing

The Make WordPress AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team needs help wrapping its arms around WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as new features get created while helping refine the existing codebase to make it more accessible to people with disabilities. Our small team can’t be everywhere and test everything, but we’re working to gather an accurate picture of what needs our help the most.

Once we have a better idea of what needs our attention the most, how do we maintain a good grasp of it? Automated accessibility testing can help in a big way here, and I’d like to start working to incorporate it into Core. I brought this up in our last Accessibility Team chat.

What’s automated accessibility testing? Similar to unit testing, this would allow developers to run a set of tests during their local development workflow of patches for WordPress via a command line tool. These tests would output results that would alert developers to potential errors and help them fix things like missing alt attributes or unassociated form fields and labels. Automated accessibility testing isn’t perfect and it won’t help us overcome all of our challenges, but it can help us find simple, easy-to-fix errors, alert us to large trouble spots within the codebase that need more manual testing and allow us cover a bit more ground. It’s a nice compliment to the manual testing and education we’ve done so far.

What do we need to consider when selecting a tool?

WordPress Accessibility Team member Karl Groves has a nice blog post about this. He says you should consider three things:

  1. Flexibility and Freedom. These tools exist for one reason only: to work for you. Every single second you spend learning the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing., figuring out how to use it, or sifting through results is a second of development time that could go into actually improving the system. The tool must be flexible enough to offer the freedom to use it in any environment by any team of any size in any location.
  2. Accurate. Developers of accessibility tools want to find every single issue they possibly can. This unfortunately often includes things that are, in context, irrelevant or of low impact. They also may require an additional amount of human effort to verify. This is a disservice. Tool vendors need to understand that their clients may not have the time, budget, or knowledge to sift through false positives. The user should be able to immediately eliminate or ignore anything that isn’t an undeniable issue.
  3. Understandable The user of the tool needs to know exactly what the problem is, how much impact the problem has, where it is, and how to fix it. Overly general, overly concise, or esoteric result descriptions are unhelpful. If a tool can find a problem, then it can make intelligently informed suggestions for remediation

I think these are good goals to try to hit. Ideally, we want something that will have little to no impact on a developer’s workflow, allow us to select different test criteria and deliver accurate results we can act on.

As research, I’ve spoken to Jesse Beach. She’s a Senior Front End Engineer at Acquia Inc., a Drupal contributor, a contributor to QuailJS (a tool Drupal uses for automated accessibility testing) and a member of the Drupal Accessibility group. She’ll help us look at QuailJS as a possible automated accessibility testing approach. And hopefully, we can share accessibility knowledge between these two awesome open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. projects! We talked about what we (WordPress Accessibility Team) want to accomplish with automated testing, how a tool might fit into a WordPress developer’s workflow, the future of QuailJS and a bit about accessibility in our different open source projects.

One other possibility on the short list of tools besides QuailJS includes Pa11y. We will likely look at others as well.

Next steps

  • Firm up a list of requirements for a tool
  • Experiment with some tools
  • Meet with Core team members to discuss
  • Develop test criteria

Your ideas and feedback are welcome!

#testing