How we’re building GC Forms: Our 4 accessible approaches

1. Set up automated tests to catch accessibility issues; it reduces manual work and increases the team’s capacity for professional and product growth.

For our automated testing, we rely heavily on the open-source Axe accessibility testing engine. Axe integrates seamlessly with our Cypress testing suite, allowing us to test web pages exactly as people would interact with them. If we didn’t have an automation set up to catch these issues, it would add a lot of manual work for our developers and reduce their capacity to grow the product.

2. Use an accessibility linter to identify issues as you’re writing code (it’s like spell check). This saves time re-writing.

We don’t solely rely on Axe’s engine for our automated testing. We also leverage tools that try to identify issues as we write our application code, saving us time rewriting after testing (because we caught the issues in advance).

For example, we use the jsx-a11y ESLint plugin to help identify issues as we build our web application. Some of our developers also go a step further and use the Axe Accessibility Linter (it’s like spell check but for accessibility issues) as an extension in VS Code, which can provide accessibility linting for HTML, Angular, React, Markdown, and Vue.

3. Set up your accessibility test file and add a few lines of code (step-by-step instructions for both are below).

To set up the file used for running automated tests, you need to add software packages to your existing development dependencies (the other software packages used in development work, not just testing ones). Add them using a package manager – it keeps track of all the software on your computer, so you can use the new testing packages in your automation.

Here’s how (step-by-step):

1. Using the yarn or npm package managers, search and add these software packages to your development dependencies: cypress, axe-core, and cypress-axe.
2. Add one simple configuration line in Cypress itself: import “cypress-axe”;

   

Alt Text: Screenshot of the line configuration in Cypress. Add “import “cypress-axe”;” under “// Import Axe-Core library

3. Configure your Axe options in your test file (read Axe’s API documentation for guidance).

Alt Text: Screenshot of how GC Forms configured their Axe options, testing for: “wcag21aa”, “wcag2aa”, “best-practice”, and “section508”Alt Text: Screenshot of how GC Forms configured their Axe options, testing for: “wcag21aa”, “wcag2aa”, “best-practice”, and “section508”

Also, as you can see in our Cypress testing file on GitHub, setting up Axe with Cypress for automated accessibility testing is accomplished by adding as little as 3 lines of code:

1. cy.visit(path);
2. cy.injectAxe();
3. cy.checkA11y(null, A11Y_OPTIONS);

Alt Text: Screenshot of the 3 lines of code in GC Forms’ Cypress testing file: “cy.visit(path); cy.injectAxe(); cy.checkA11y(null, A11Y_OPTIONS);”.

1. Train developers on at least one assistive technology to bridge knowledge gaps between a web application’s appearance and functionality.

Developers often focus on the visual or sighted version of a web application. They may put more effort into the appearance of an HTML component and interaction, than into ensuring the component follows best practices in HTML layout and labelling.

We strongly encourage our developers to familiarize themselves with at least one assistive technology (NVDA, JAWS, VoiceOver, etc) – enough to be able to navigate and interact with a web application. When we asked our developers to use an assistive technology to navigate GC Forms, an interesting thing happened: they became frustrated. Re-framing their mindset from focusing on specific WCAG success criteria to focusing on user experiences showed improvements were needed, like providing more informational context.

2. Update the team’s development processes to assign responsibilities around usability checks.

In our development process, each developer is responsible for the usability of components they’re building or modifying. They need to ensure components are accessible both visually and with assistive technologies.

With this process update, we quickly saw a shift of focus away from ensuring a visually perfect box-shadow, to thinking of ways to improve the interactions of components they’re building. This greatly increased the usability of our complex web application interactions, like uploading a file in a web form and submitting a web form after a set period of time (spam prevention).

Guidance to help with GC design research

We’ve created resources to help plan your testing methods and run research interviews, and we also offer a service to help you generate privacy and consent forms for research sessions.

How design research improved experiences using GC Forms

When developing the forms product, we conducted design research to test our assumptions about accessibility. This included running two design research activities with 12 people who use assistive technologies to navigate government services. We had 10 users complete a mock form and provide written feedback about their experiences completing the tasks. We also had 2 users narrate their experiences as they navigated and completed the form, providing us more detailed information on their user journey.

Each research participant used their preferred assistive technology and browser:

• Dragon NaturallySpeaking with Chrome;
• JAWS with Edge;
• MAC built in screen reader with Safari;
• NVDA with Chrome;
• NVDA with Internet Explorer 11;
• OS Magnification with Firefox;
• On-screen keyboard with Chrome;
• On-screen keyboard with Internet Explorer 11;
• Voice Control with Firefox;
• VoiceOver with Safari; and
• ZoomText with Edge.

One of the insights from these activities is that people don’t know what “Alpha” means, so it was confusing that the banner on our forms had “Alpha: This site will change as we test ideas.”

“I find that the word alpha is a little bit out of context because I can’t think of what it would be related to and where in the form it would be relevant” – design research participant

It was clear that while “Discovery, Alpha, Beta, and Live” mean something to us (they’re agile development stages for product releases), it doesn’t necessarily mean the same to people completing GC Forms. So we removed it, avoiding the unnecessary distraction and reducing confusion for users.

Tip from our experience: the WCAG checklist is too big for any one person to keep in mind all the time – try breaking down the requirements into smaller bits of work and integrating them into different parts of your product processes.

To help prompt thoughts around accessible experiences, we have placeholders in every user story, unique to the work.

For example, when we’re developing a new component (such as a button to upload files), we make sure it’s keyboard navigable and that a screen reader provides the information needed to upload a document. We implemented the navigation check as part of the “definition of done” and “acceptance criteria”.