Coming back to that building accessible by default and by design, in those early days, we did some research with public servants who use assistive technology to understand the output formats that they use. Government often runs on Excel and PDF, but no surprise there. There’s some difficulty with using those programs. We had one public servant who, because of the machine that they had, it would take them five minutes to open up a larger PDF. And then also getting to an Excel file was difficult to navigate. 

So the first data output that we started with was in HTML format. Whatever, whenever you get your data, there will always be a format in HTML that is easier for you to navigate, that works with the assistive technology that you’re using. 

For a few folks in government, they wanted CSV right away. We started with HTML because of that early research that we did as public servants. CSV is also a thing in Excel, but HTML has proven over and over to be the most accessible language to look at different forms and different ways of navigating data.

1. New feature idea proposed: So usually it begins like you mentioned in wireframes. So we have a collaborative tool called Figma. A designer will come up with a new idea for a feature based on product decisions and so on.
   
2. Team thinking on accessible design: Then, right from the beginning, myself and other developers start talking about the design. Wherever users struggle, we try to think about the usability and accessibility holistically so we can add comments to the design and start asking what happens if this user clicks here or they get confused by this? Have you thought about this contrast and so on? That really helps because we get the conversation going with the designers and developers.
   
3. Building and automatic accessibility testing: When the developers go to start building it, we already know what we’re building. And then once it’s ready to be tested, we have automated tests that run and look for WCAG conformance 2.1 AA and other things. That runs automatically by default with our build process once it’s ready for testing. 
   
4. Team manual accessibility testing to avoid tunnel vision: Then manual testing comes in from myself and especially other people on the team that aren’t so close to the feature. Because as a developer, if I build it and stare at it, I will always have tunnel vision. To this point, I will miss a lot of other things, so other people come in and help test, which is very helpful. While that’s going on, I have my own little mental checklist from years of experience. Is everything keyboard navigable? Is this beyond even accessibility, say a touch pointer device for mobile phones: is this click target big enough to actually reach this? Basic stuff like that. Once that’s done, maybe we’ll iterate on the feature a little bit more if we have even new ideas, go back to the design process, look at the Figma, and move forward.
   
5. User testing and accessibility improvement: Then when we’re able, we get real users to test our product using the Fable service. They test it, and then give us a score. Based on their feedback, we iterate again on any changes. It’s a consistent loop we have going.
   

You may be interested in this blog, “How we’re building GC Forms: Our 4 accessible approaches”.

So from a high level, we have the basic checklist and guidance the W3C provides that anyone can follow to make sure your site is accessible. So as long as we reach those, we’ve sort of got I guess you could say, a step towards conformance.

Then, of course, we also use the WCAG manual to achieve conformance. And that’s great, but the problem is you can have a website that’s both WCAG conformant and not accessible.

For example, there’s a lot of subjective parts of WCAG that are left up to the designer and/or developer to figure out. Alt text is one, link text is another. For example, if all the links say click me, how many users like going through an outline? It’s not very helpful. They really can’t use it without going through and figuring out where each link goes. And some of those links might even have consequences. Like if you click on a link, maybe it submits something (so they might even be afraid they actually cannot use it). There’s a lot of examples like that.

Luna: It’s fantastic because you’ve just given people a glimpse into the fact that adhering to a standard doesn’t mean it makes it accessible. 

So, it’s been about five years that we’ve been developing the product, doing research, and building up the solution. And we didn’t always have a ton of accessibility expertise embedded on the team. So one of the things that CDS did early on was we allocated Fridays for professional development. We give folks time to dig into topics around accessibility, security, even things that interest them that might improve the product a little bit later. 

Famously, Gmail was made out of these development times out of Google. We’re trying to take a little bit of a similar approach. While we’ve got Pete here today, we’ve got a full team of developers that are all at various stages along this journey and testing manually, whether it’s with VoiceOver or Jaws or NVDA to try and go through and test what they built.

So it’s a combination of giving people time to study and learn. We ask people to post on our team Slack what they’re researching or learning about on Friday. Essentially, we share the expertise across the team, make it everybody’s responsibility, and give people time to learn more about the topic.

Nadine: So let me tell you a little bit about why I use GC forms. One of the first times I’ve used it and it was HR related. So if you’re going to do a talent management appointment or a non advertised process, you have to do a Statement of Merit Criteria (SoMC) and you have to provide justification. And, you know, those old forms of using a table in word, right? Aren’t they horrible?

Using GC Forms, the HR forms are now completely accessible. I can put a SoMC in there, it’s Protected B, and I can fill out the information that I need and send that off to HR. They can comment right in the form and it makes it so much easier and again completely accessible, which was  fantastic.

Luna: HR processes are generally inaccessible and so complex. Having filled out many of those assessments against SoMCs as a manager, I know how long it took me using a screen reader to go through those tables. So this is amazing. And it’s amazing to think that those who will come after us will have it easier and easier because of initiatives like that.

We’re working on a feature that will allow people to add file attachments to their forms. So if an individual needs to append, let’s say a driver’s license or proof of ID or something like that, you’ll be able to get that data via GC forms.

This fiscal year, we’re looking at improving editing forms after they’ve been published. One of the catches on the product right now is that it’s a little bit difficult to edit a form. Once you’ve published it, you have to take it down and then republish it, which is not ideal. 

Also, a little bit of a drawback right now that we’re looking to fix this fiscal year is creating a way so that teams can manage multiple forms, with different roles for different people.

Check out the GC Forms roadmap!