Build accessibility into your agency’s workflow from the beginning.
8/20/2025 6:05:08 PM
The US Department of Justice (DOJ) added digital accessibility requirements to the Americans with Disabilities Act (ADA) for Minnesota’s state and local government entities. This new rule puts into writing practices that the DOJ has followed for decades. Our Update to ADA’s Title II series digs deeper into preparation and implementation resources for state and local governments as they work toward compliance.
In this series, we’ve explored how agencies can prepare for the new rule. We’ve covered understanding your current accessibility scope, setting priorities, and building implementation plans. This month, we turn to a critical part of the process: quality assurance (QA), and how accessibility testing fits into the development lifecycle.
We spoke with Angela Marckel, a QA Analyst with MNIT’s Enterprise Technology Delivery Project Management Office (ETDPMO), who has spent the last decade integrating accessibility into IT projects across the State of Minnesota.
Angela describes QA as “making sure the right steps are followed, and that what we build works well for everyone.” That includes accessibility. Whether software is purchased or built in-house, QA ensures it works for all users, including people with disabilities.
For Angela, accessibility is fundamental. “It’s as important as any function of software,” she says. “I have long seen it as the underdog and tried to champion its importance.”
While developers test their own work during sprints, QA brings a different lens. “Developer testing is often about speed, making sure the ‘happy path’ works,” Angela explains. “QA testing looks at the details, including what happens when things don’t go as planned.”
QA also considers accessibility in places others might overlook—like error messages or admin tools. “Even if current users haven’t self-identified, they may still rely on accessibility features,” she says. “By ensuring accessibility, we ensure future users don’t have problems.”
Angela frequently sees issues like:
When issues come up, she logs them like any other problem, whether in a dev-test tool, Excel, or SharePoint. In fast-paced Agile environments, she may alert developers directly for a quick fix and retest.
Angela’s approach is practical: assign the issue, suggest a fix if she knows one, and sometimes fix it herself. “If it’s something like missing alt text, I’ll fix it and let the team know.”
She always retests the fix and the surrounding area: “If a screen’s tab order was the problem, I retest the entire screen, not just the fix.”
Angela tests each item for accessibility as soon as it’s ready. Early testing prevents problems from spreading and saves time later, because the developers have fixed it once so will include it the next time.
She also makes sure accessibility is retested after any changes. “Following the usual process helps prevent things from slipping through.”
Angela offers practical advice for making accessibility part of everyday work:
She also encourages sharing success stories: “When teams share how they incorporated accessibility, it encourages others to do the same.”
Angela recommends:
Angela’s insights show that accessibility enhances quality assurance, making it a core part of building stronger, more inclusive software. By embedding accessibility into workflows, QA teams help ensure digital content and services are usable by everyone, now and in the future.
A list of resources related to this third part.
OoA Articles:
Department of Justice:
Would you like to learn more about the accessibility work being done by Minnesota IT Services and the State of Minnesota? Once a month we will bring you more tips, articles, and ways to learn more about digital accessibility.
Accessibility
Accessibility
