The Nelnet Accessibility Team will draw on its experience building accessible websites to describe points in the software development lifecycle where accessibility should be considered. We will show that accessibility is a team game where all stakeholders share responsibility. By integrating accessibility into the development process and understanding the ways that different roles contribute, we will explore how teams can “put people first” and create a better product for all.
Accessibility testing is a vital step for ensuring an accessible end product. But it shouldn’t be the only step. Many issues are easier to fix if discovered earlier in the project lifecycle. When they aren’t, tight deadlines may lead to a sub-optimal solution due to constraints imposed by the already established design and architecture of the application.
In this session, we will draw on our experience building accessible websites at Nelnet to describe points in the software development lifecycle where accessibility should be considered. Similar to adopting secure development practices or increasing code test coverage, while the upfront investment is significant, it ultimately saves time in the long run. Integrating accessibility from the start results in less risk, fewer accessibility issues discovered during testing, and a better end product.
Building accessible products is a team effort. Designers need to know how to design accessible interfaces. Content writers need to know how to write accessible content. Developers need to know how to implement accessible features. QA needs to know what to test for. And stakeholders need to be invested in the value of accessibility to enable the team to make it a priority. This is a tall order; all of these groups have other concerns competing for their time and attention. Engaging these groups early and keeping communication open is a key part to building the knowledge base needed.
Nelnet employs a fully agile development process using the scrum methodology. A frequent release cycle has many benefits for development teams and customers alike, but it also poses some challenges. It can be tempting to get a release out the door and worry about accessibility later, or hard to fit in the thorough accessibility testing that we would like to see. This has only increased the importance of making accessibility an integral part of the entire development process. And when we do, the increased sense of team ownership naturally counteracts those possibilities. Clearly defined acceptance criteria that include accessibility related behavior and making accessibility part of the definition of done are some of the ways that teams are making accessibility a priority. We are exploring ways to engage teams and provide them with the knowledge and tools they need to accomplish this.
Today there are many great tools available for accessibility testing. These tools can be leveraged to help teams visualize how certain techniques affect the accessibility of a web page, check for many common issues themselves, and reinforce best practices. Another key item in the Nelnet toolbox is our accessibility checklist. Written with developers in mind, it is not just a tool for testing, but also aims to teach why the criteria are important and provide techniques for implementation.
As we look to the future, we are always searching for ways to improve. A promising area is increasing the amount of automated accessibility testing we do and integrating it into the build process. This will provide teams with immediate feedback for those issues that can be caught programmatically.
Accessibility needs to be considered during the entire project life cycle, not only when testing. By integrating accessibility into their development process and understanding the ways that different roles contribute, teams can “put people first” and create a better product for all.
- Discover how accessibility fits in the software development lifecycle for waterfall and agile methodologies.
- Learn ways to support the software process with training, documentation, pattern libraries, etc.
- Explore how different stakeholders can focus on different parts of our overall accessibility requirements.