Ajouter un commentaire
by Jesse Beach
Usability and accessibility testing
On Friday, July 19th, 2013, two usability tests were conducted in the labs of the University of Minnesota. We set up the tests with the intent of establishing the usability of the content creation experience. Two participants, one blind and one sighted, attempted to create an article node. The testing script is available publicly and open for comment.
The preliminary findings are being compiled and analyzed. We will publish the final results very soon. The findings document is open to comment.
Thanks as well to Terrill Thompson for coordinating resources and communication. To Chad Fennell for arranging the testing space and to Tonu Mikk and Philip Kragnes for additional support and coordination.
Executive takeaways from testing
- Drupal is not as accessible as we even dared to hope.
- Content creation is painful and at points impossible for a non-sighted user. Something as fundamental as the content creation process should present the least number of barriers. Most of the issues encountered stemmed from interface issues such as the inaccessible structure of the Overlay module.
- Form validation errors are invisible to a non-sighted user.
Accessibility presentation on Saturday
I gave a presentation about efforts to improve accessibility in Drupal 8.
The session was conversational. Attendees were invited to provide their personal definition of accessibility. We then watched and listened to clips from the previous day's testing. The clips triggered further discussion. I was pleased to see so many familiar faces from the development ranks of Drupal. Our group for the session also included accessibility experts, project managers tasked with making their web properties more accessible and interested developers new to Drupal. All in all, we had a great, diverse group of people invested in making Drupal more accessible and frankly, delightful for everyone to use.
Executive takeaways from the presentation and discussion
- Accessibility is more than non-visual interfaces. Users interface with systems through a variety of mechanisms such as sip-and-puff machines.
- Some screen reader users find the hierarchical page navigation (drilling in and out of landmark regions like navigation) confusing, because they need to keep a map in their minds of how far they've drilled down into a page. This is kind of pogo-sticking with an aural interface.
- Project managers want quick, consumable, concrete actions they can take to make improvements to the accessibility of their properties.
Remediation of issues at the sprints on Sunday
Brandon Bowersox-Johnson and I spent the morning of the sprint tagging issues in the Drupal 8.x issue queue for accessibility and
TwinCities. We then set to resolving the most pressing issues, most of them observed during the testing two days prior. Matt Parker participated remotely.
We also welcomed two new drupal-contributors-in-training: Catherine McNally and Yvonne Cariveau. Both of them bring incredible knowledge of accessibility best practices and remdiation techniques to our burgdeoning interest group. They spent the day in breakout training sessions learning to install Drupal and write patches. I can't wait until they're proposing their initial code changes to core!
Issues addressed with a patch
- Make the status message field discoverable by assistive technology agents; alert AT agent users to error messages
- (Committed!) Remove redundant [role=navigation] in the header around the breadcrumbs in the Seven theme page template
- Label used for markup, not associated with input form
- width:1px in visually-hidden class causing problems for screen readers in Firefox
- Label missing in Page: The title of this view & The menu path or URL of this view
- Page: Theming missing Label
- Remove empty headers in Views UI
- Allow forms to set custom validation error messages on required fields
Issues worked on
Many weeks and hours went into the planning of the accessibility-focused events at Twin Cities Drupal Camp. Everyone involved should take a moment to consider that we arranged a sophisticated series of events with smooth execution and ultimately success.
We set out to discover the major gaps in Drupal's accessibility support regarding one of its primary function -- creating content. The tests clearly revealed these gaps and set us on a solid path to remediating them.
The camp weekend also brought together many individuals who have only known one another remotely. Working with somone in real time is invaluable to forging a successful collabortive relationship.
We have already made much progress to fix the issues we found in testing. And soon we'll more folks helping to identify and resolve additional pain points within Drupal's user interface.
Acquia sponsored my travel to Minneapolis and the Twin Cities Drupal Camp. This time was vital for me to establish better working relationships with the folks in the accessibility community. This weekend, like Toronto in 2012, will be one of the key events in the chain of our efforts to improve the accessibility of Drupal for everyone.