Home Blog Enhancing the accessibility of a plugin, a use case – WordCamp Europe 2021.

Enhancing the accessibility of a plugin, a use case – WordCamp Europe 2021.

07-06-2021

At WordCamp Europe 2021, Morgan Kay and Rian Rietveld gave a presentation about Enhancing the accessibility of Gravity Forms.

In this post we (Morgan and Rian) publish the content of this presentation, including the links to the resources mentioned.

Introduction

Morgan Kay is a software engineer at Rocketgenius, where she works on the product team making Gravity Forms .

Rian Rietveld is a web accessibility specialist working for the WordPress agency Level Level. She is also a trainer for The A11Y Collective, an online learning platform for web accessibility.

Let’s talk about: Enhancing the accessibility of Gravity Forms, a use case.

Gravity Forms is a form building plugin that lets you easily create everything from simple contact forms to complex e-commerce solutions and just about anything else you can imagine doing with forms.

Gravity Forms recently launched version 2.5, which introduces some major changes to the plugin. One of the goals for 2.5 was to make sure that it was possible to build accessible forms. To help us do this, we called in an expert: Rian.

Forms on your website give your visitors the possibility, for example, to contact you, log in, order products and services or subscribe to your newsletter.

Forms need to work. No doubt about that. They need to work for every visitor. That is why accessible forms are so important.

Where are they now for the frontend forms, accessibility wise? Rocketgenius asked Rian to do an initial accessibility review.

The accessibility review

Where to start? Well, with the guidelines. In this case WCAG 2.1 AA. WCAG stands for web content accessibility guidelines, at the moment the latest version is 2.1, and we tested against level AA, the global standard.

And of course the HTML5 must be perfect and semantic, we tested that against the HTML Living Standard.

What to test?

The goal was for version 2.5, that users can create fully accessible forms at the frontend. So Rian went through all the form controls, the settings, the options, and combinations and checked their accessibility.

Some of the tools we used are:

A keyboard, everything should work with a keyboard only
The browsers inspector of Chrome and FireFox, to check the generated DOM and the accessibility tree
Screen readers: VoiceOver for Mac and NVDA for Windows. Do blind visitors get the feedback they need?
axe DevTools, to check for accessibility and parsing errors
W3C Validator website: validator.w3.org for correct use of HTML5

Next to the review, Rian also met the team during the week of the Rocketgenius Christmas party in Norfolk, Virginia, just before the lockdown.

To get to know everyone she would be working with. She gave an introduction about accessibility to the team. And explained to Michelle Bauer, who does the Quality Assurance for Gravity Forms, how to test and review for accessibility.

What came out of the review?

Well, the most important improvements were:

Better feedback for screenreader users, for dynamic changes, announcement of changes in the form, that you can see, but also must hear.
Better keyboard accessibility, all functionality should work with a keyboard only.
Better feedback on form errors, and that is beneficial for all users.

Implementation

When the Gravity Forms team received Rian’s review, they handed it over to the QA expert, Michelle, who created issues in Github. Then took the issues one by one, discussed how they were going to solve them, and discussed potential solutions with Rian before implementing them.

Rian gave the Gravity Forms development team a lot of great tools and advice, but implementing her recommendations wasn’t always straightforward. There were three major concerns that made implementation difficult:

Backwards Compatibility

Gravity Forms has a commitment to backwards compatibility. We want to make sure things won’t break when you upgrade. Version 2.5 has some major markup changes, so this release breaks things more than any other, but even then, backwards compatibility was a concern.

For example the multiselect form field.
Multiselect is inaccessible, there’s no workaround or solution and Rian told us to just get rid of it. But what about forms that already have it? We have to keep it, but it has a warning label on it so users know it’s not accessible.

Flexibility

We had some extra challenges when thinking about the infinite variety of forms our users create and how to accommodate that. Users do some amazing and creative things!

Example: Validation messages
For accessibility, we should have a box at the top of the page listing every field that has an validation error, showing the error, and linking to the field. That makes sense if you have a form with a lot of fields. But it looks silly if you have a form with one or two fields

So we decided to make the default behavior match earlier versions of Gravity Forms: if there is a validation problem, there is just one message at the top, but you can turn on the option to include a summary of all the validation messages

Support

We want to make things easy for our users, and also for our support team.

Making drastic changes to how Gravity Forms behaves is frustrating for users, and creates more work for support.

Example: sublabels below inputs.
Gravity Forms has always done this. We don’t know about you, but Morgan knows a site is using Gravity Forms as soon as she sees the name field with the sublabels for first name and last name. Rian recommended putting the sublabels above the inputs. It’s a recommendation, not a WCAG violation.

We decided to leave it as is to match user expectations. So that means some of our default settings aren’t totally accessible… which brings us to the next important step: communication with our users.

Communication

We needed to teach users what is important to set up an accessible form. Gravity Forms now provides accessibility documentation in the online knowledgebase:

Commitment

First: The Gravity Forms Commitment to Accessibility, to aim for the forms to comply to WCAG 2.1 AA: the Web Content Accessibility Guidelines, version 2.1, level AA. This means that the forms also comply to ADA, section 508 (US), the European Accessibility Act and the Equality Act 2010 for the UK.

User guides

Accessibility guides with what is important for:

An overview of the accessibility warning showing on fields, when you add a field or setting with accessibility issues.

And last but not least a Accessibility Checklist for Gravity Forms.
Which takes you through settings and options for forms and fields to help educate you as to what (and whatnot) to use for better accessibility of your forms.

Inline warnings

Inline warnings in the Admin when you use a setting or form control with accessibility issues.

Support

A prepared support team that knows how to report and give feedback to tickets with accessibility issues and questions.

Conclusion

What did we learn in the process? What can we give you as the main takeaways?

Make a plan to implement, also think of backward compatibility and user expectations. Don’t break stuff for users.

Get everyone on the team onboard and motivated. An expert can provide guidance, but a development team still needs to learn the basics and to think about accessibility every step of the way. And the team of Gravity Forms did an absolute great job at that.

Get help from outside or appoint an a11y expert in house, it’s impossible for a developer or designer to know everything about web development. There is no way we could have done this without the help of an accessibility expert. Even though the Gravity Forms team knew the basics of accessibility, the details were complicated and we needed (and continue to need!) expert input. There’s too much to know.

Help the user with inline warnings and with documentation and set accessible defaults, train the team and prepare support.

Are we done? Nope: it’s constant monitoring and learning. Features are added that need to be checked. Support tickets come in and need to be addressed. And accessibility guidelines change.

But it’s totally worth the effort because you end up with a better product and it also forces you to look closer at your work, your workflow and quality assurance.