"Shift left." "Start accessibility earlier in the project life cycle." These phrases help us think about embedding accessibility early in a project. It is easy to agree that this is important. It can be more difficult to integrate this into everyday practice. To be successful you need to know: 

• How accessibility plays a role at each phase.
• Who can champion and contribute to this inclusion.

One recent project successfully moved accessibility to the left.  Staff from the Minnesota Department of Education (MDE) and Minnesota IT Services (MNIT) worked together to make the shift. Three project team members spoke with me about how this improved the project’s outcomes. They also shared how this changed their approach to future projects. This month we learn from:

• Courtney Petrosky, Project Management Supervisor, MNIT partnering with MDE.
• Kim Wee, Webmaster and Digital Accessibility Coordinator for MNIT partnering with MDE.
• Tamera Williams, Contractor - Project Manager / BA for this project, MDE.

Project History

Petrosky shared, “This project started because we have an existing homegrown application. This application is over 10 years old.” There were quite a few challenges with it, including the required upgrades and maintenance, as well as needed changes. MDE decided to replace the application. 

"We started with a feasibility study, interviews, and research. Tamera began working as a contractor to complete this work. This resulted in the decision to do a Request for Proposal (RFP) and bid out for a vendor to provide a solution. We were looking for a cloud-hosted solution, with the product end supported by the vendor."

Agency vs IT Department Roles

IT projects completed in government typically have 2 groups working together: the agency and the IT department. Williams shared more about how this works: MNIT owns the contract - the acquisition of the technology. And they facilitate the technical work. They identified the need for a cloud-hosted solution. They help the agency understand which vendors have products that can provide solutions that may meet the business needs. "We had a very deep team on the MNIT side. In addition to Kim Wee, we had people from security, network engineers - there was a lot of input to understand what we need to do and what's going to fit in our current environment. The business or agency side - they know the practice. We had long periods of time where the business was working on designs, applying their processes...it's a lot of work for the business."

Motivation to Change Accessibility Approach

Together, Petrosky and Wee had previously worked on projects that included accessibility testing of products. Petrosky shared that they found "there were some gaps in how we were applying those practices across the board on all of our projects. We really wanted to dive deeper into a new project, and this became our opportunity." They also had strong accessibility advocates on the business team. "MDE is the real project owner here," shared Wee. "They have an enormous amount of influence."

Perspective Change

Williams was new to having accessibility included in a project. "I focused on the functional requirements, what the business is requiring. It's been a learning experience for me as a project manager, someone helping to move the implementation forward." She shared that she needed to learn "how to make sure that we have the right resources in place to actually address or to ensure accessibility."

As a project manager "there's a lot of time and resources required to ensure that accessibility is being considered, and is not just a side thing. It is a part of the functionality or the functional requirements. That was a big aha for me. It's not something we wait for the end to just kind of confirm or verify. It really takes time to ensure that it is in place when you get to the end."

Wee also found that accessibility as a functional requirement was "a huge lesson learned. I think it impacted this project in ways that I never would have anticipated. And I think it really led to the buy-in. This impacted the project from all sides, including the buy-in from the business and vendor’s team members."

Petrosky found that this project impacted her thinking from a project management standpoint. It helped her consider "other phases of the project where I never thought about accessibility, or including Kim in those kinds of conversations before. As a project manager or even as a supervisor we don't want to waste people's time in meetings if they are not needed. But what I've learned through this project was that if (in previous projects) I had brought Kim into conversations much, much earlier it probably would have reduced some of the later conversations. The important part was sitting in on the design discussions." She used to meet with the business team members, then connect with Kim, then go back to the business team members..."I should really have brought them together in the same room so Kim could do that feedback instead of me."

Because she was considering this expansion of accessibility discussions throughout the project life cycle, Petrosky also sees a need for more accessibility professionals available to teams. "We only have Kim - this is what I hear from many of my project managers. We need her on all of our projects. That's our next big challenge - strategizing, getting more support, so we can get accessibility in all phases of a project lifecycle."

Operationalizing Accessibility

Operationalizing accessibility means each role on a team needs to have accessibility knowledge specific to their role. In addition, you need people with deep accessibility knowledge. Petrosky shared that "Kim has been working on more training for the developers and the quality assurance team." This will help expand the accessibility knowledge of more project team members. “I know there's still going to be a lot of need for Kim (on projects) just because she has years of knowledge that would be difficult to translate to all of our staff. We have discussed questions like what are some easy ways of starting to get developers familiar with the tools that Kim uses for testing? We need a curriculum, and we might need to even think about something annually, to continue to refresh staff and as we get new members. It's going to be a project in itself to come up with a training strategy and documentation."

Williams added that "Kim really provided consultation guidance as well as direct training with our vendor. They came up with a guiding document that they're using with their developers as a result of that." As the project progressed, MNIT and vendor staff identified gaps, and Kim helped train in those areas of need. Accessibility is a journey, and this partnership helped ensure everyone could play their part in creating an accessible product that met the requirements.

Importance of Development Team Check-ins

Wee had regular check-ins with the developer and development team. This began early in the process, after vendor selection. Together she and the lead developer reviewed code for potential accessibility issues. "We started with talking about ARIA labels (attributes that supplement HTML) because after an initial assessment that was an identified area of risk." They talked about: 

• Ways to use ARIA labels in the identified framework.
• Checking if it was on the correct tags. 
• Testing. 

"Those kinds of conversations were so imperative. Detailed. Scoped to what we needed to do. It was imperative to this project to get us moving in the right direction for the developers. It also led to future enhancements. The developers now have repetitive code libraries and a documentation guide" that reflects the work they did together. They can use this on future projects.

Tracking Accessibility Issues and Requirements

Petrosky shared that one of her favorite resources from this project enables her to better track the accessibility work. "I'm a list person. Tamera created some really good templates in an Excel table [that helped us] track all of the tickets that needed to be worked on, where accessibility was included..." This was "very helpful for that communication and collaboration between the vendor, MNIT, and the business when communicating what things had been found." They could review the status and resolution of tickets. “Because this was a vendor product project and not an internal project, we didn't have a tool that we could all use." Williams used these when facilitating meetings to help review issues and streamline the conversation. This added structure to the test plan. Williams said that the vendor developers used this list to "test and validate, and then Kim can follow up and confirm."

Advice for Moving Accessibility Earlier in a Project

Williams shares advice for those newer to integrating accessibility throughout the project life cycle. "I think the big thing is being flexible. Really try to lean on those that have the gifts and talents. I leaned on Kim, Courtney, and others to really try to make sure that I was understanding where we needed to go. Be able to really listen, to be able to assess where there are gaps.”

The state of Minnesota’s digital accessibility standard impacts the work everyone does throughout the project life cycle. Take time to learn your role, and how your work impacts accessibility. Connect with your digital accessibility coordinators to learn more, and keep learning. Like this team, each time you shift left, you are improving the accessibility of your work, and contributing to making all of our work more efficient and accessible.