By:

• JoAnn Rautio, Minnesota IT Services partnering with the Department of Employment and Economic Development, and
• Jennie Delisi, Office of Accessibility

You may have said to yourself: accessibility testing should be part of a technology project's workflow. The questions your colleagues may ask next are "who will do that?" and, "how does that work in real life?" The answers to both questions are:

• It takes a team of people, working together.
• It takes time to mature the process, catch all aspects of each type of workflow.
• And, it is an ever-evolving process.

This month we learn from the team of state employees who work on and support the Workforce One project. Some work for Minnesota IT Services (MNIT) – the state of Minnesota's IT department. Others work for the Minnesota Department of Employment and Economic Development (DEED).

According to DEED, "Nearly 2,000 state, city, county, and non-profit employment and training providers use Workforce One (WF1) to track employment and training services to more than 100,000 customers across Minnesota's One Stop network." WF1 is a web-based client management application. It "was created through a partnership between the Department of Human Services (DHS) and the Department of Employment and Economic Development (DEED)."

JoAnn Rautio, Quality Assurance (QA) and digital accessibility coordinator for MNIT partnering with DEED, has a significant history with the team. "The WF1 project began in 2011, and I started in 2014 on that project. In the project scope they included that it was to be designed and coded as accessible for all users." More specifically, according to Annie Tietema (former product owner), they felt a commitment to creating and enhancing the accessibility because:

• "At DEED, we serve internal and external customers for whom we must provide accessibility systems per the law.
• It makes systems more usable for everyone.
• It helps us attract a more diverse pool of employees.
• It's the right thing to do!"

Rautio feels that "to truly have accessibility in the application lifecycle, it has to be part of everyone's role." This digital accessibility culture is how the MNIT partnering with DEED team approaches all their work. "It is everyone's role to create and enhance the applications for all customers." And when asked how the team approaches accessibility, Rautio reports their approach is positive. "Digital accessibility is a work in progress and we continue to grow. DEED has taken a proactive step by creating the Performance and Technical Management team which is committed to providing accessible systems."

Tip 1: Have a Leader Who Champions Accessibility

Brian Allie is the Chief Business Technology Officer for Minnesota IT Services Partnering with DEED, Commerce, the Public Utilities Commission, and Explore Minnesota. He shares, "In my role I have both a legal and moral obligation to champion accessibility in the entire Software Development Life Cycle, whether that be developing or purchasing software. As an organization we need to emphasize that accessibility, like security, is part of the process for any software implementation."

Leaders play an important role in ensuring that everyone can address accessibility in their role. Allie explains, "This means giving teams the tools they need to accomplish that and giving accessibility testing the same level of value as all of the other testing that goes into software development."

Tip 2: Check Technology Tools Before Using

Many industries talk about doing checks or reviews before starting something. For example:

• Know Before You Go – U.S. Customs and Border Protection.
• Know What's Below. Call Before You Dig – Minnesota's Office of Pipeline Safety.
• Check. Call. Care – First Aid.

Bridget Fitzgerald, MNIT partnering with DEED's Project Management Office Supervisor and Technology Intake Coordinator, kicks off the important workflow around checking accessibility for requested technology. She says, "DEED staff are continuously submitting technology requests to me: requests for software tools, applications, and plug-ins to make their work more effective and efficient. When they do, the requests must be vetted for accessibility."

There are more paths to follow, depending on the type of product. "I route these requests to our MNIT Accessibility Coordinator, JoAnn Rautio. She:

• reviews the company's completed Voluntary Product Accessibility Template (VPAT),
• runs accessibility tests on the requested technology, and
• scores the tool's accessibility.

We double-check with the MNIT Enterprise Accessibility office, to see if the tool's accessibility has been tested by other agencies. When we send out Requests For Proposals (RFPs) or contract with a vendor, Accessibility is part of the equation. We want to know

• how the vendor approaches accessibility in their tool,
• if it can be used without a mouse,
• if they have coded keyboard shortcuts.

An accessibility review is part of the new technology intake process."

Tip 3: Include Accessibility in Product Approvals and Priorities

Becca Johnson is the Workforce One product owner. Johnson says, "The WF1 Team keeps accessibility at the forefront of every system enhancement, and as the Product Owner, I am responsible for prioritizing new or updated functionality to ensure our system is functional, compliant, and user-friendly for all. I am the final level of approval for system enhancements and communicate/demonstrate changes to users in a way that is accessible for anyone, regardless of any hidden or visible disabilities."

Tip 4: Practice Accessibility Regularly to Improve Outcomes

John Dufner is the business analyst on the project. He explains, "Accessibility is a fundamental component of our Workforce One Project. All of our application development has an eye towards users who require some form of accessibility need. Therefore, once coding is complete, as a business analyst, I test the page not only for functionality but also for accessibility. I use add-on tools to assist me such as WAVE, AXE, and JAWS in addition to performing keyboard testing. Using these tools frequently changes your mindset so that you start to envision pages with an eye towards accessibility. This can be seen in page layout and structure."

And, accessibility testing done by the team has other benefits. Rautio explained, "All roles have responsibilities to test for accessibility to prevent bugs. Similar to other development bugs, accessibility is considered a bug if not coded correctly from the spec. It is valued the same as a unit and exploratory testing. We all learn from the errors because we have to take time to document the issues."

In conversations with this team, everyone worked on their general accessibility knowledge. That allows them to play to their strengths, experience, and training in their specific areas. The digital accessibility coordinator or subject matter expert can come in with that deeper accessibility knowledge and fill in any accessibility gaps. This capitalizes on their expertise and specialty skills. And, they can provide additional training for the team as needed.

Tip 5: Build Upon What You Learn

Finally, when asked what is one tip Rautio would share based on all the learning this team gained in the last 14 years, she shares, "Continue to learn. Continue to improve." Doing this helped Rautio and the team learn new techniques, discover new tools, and continue to refine the way they work together. It helped them "improve our jobs and make them more efficient."

Bonus Tip

Newer to having a team digital accessibility approach? This team shared 3 tips just for you!

1. Become a champion. Talk to your digital accessibility coordinator and project manager about wanting to develop this with your team.
2. Add the free WAVE, axe, and ANDI extensions to your browser. Scan a project page. Talk with your teammates about the results.
3. Be willing to adjust the process. Be Agile –
   1. What worked well (keep doing!).
   2. What didn't work well.
   3. What will we do differently!