Accessibility is one of the key focus areas for organizations worldwide. As we move towards a world that is increasingly getting software-defined, it is essential to ensure that all users can ably use a piece of software, irrespective of any disabilities. The government, having recognized this need for inclusiveness mandates that all software (websites, applications, documents, native mobile apps, etc.) follow the compliance standards as set by Section 508.
For software development, this means that making good, error-free software is no longer the only barometer that measures product quality. The standard of product quality has to be determined, amongst other things, by its capability to meet the needs of ‘all’ customers – including ones with disabilities. This becomes even more essential in the age of digitalization where government agencies are becoming software-driven and also adopting DevOps as a popular development methodology.
With Section 508 compliance in place and it has undergone substantial iterations, government agencies want to ensure that the compliance standards meet the demands of the current society and channel inclusiveness. However, inclusiveness, in this case, is not limited to the end-user alone. This section also demands that along with the end-user, accessibility should not be limiting for the resources developing these products as well…which brings us to DevOps.
DevOps is gradually working towards becoming the gold standard as a development methodology. People, process, and technology are the pillars of DevOps. Keeping Section 508 in mind, organizations leveraging DevOps have to make sure that accessibility is not a barrier for developers and that equal opportunities can be provided for all. This means organizations have to take a close look at their tools ecosystem and evaluate if these tools are meeting the accessibility needs of the developers.
Developers thus have to be given access to tools that support accessibility. Jira, for example, is one of the most popularly used project management tools. Atlassian, the company that brings us tools like Jira and Confluence, has strived to be accessibility friendly for any context or range of ability, be it temporary or permanent. Keeping this in mind, Addteq has developed Unstoppable, an application that makes Jira and Confluence even more accessible. Unstoppable allows Jira and Confluence instances to be compliant with Section 508 and offers developers ease of use.
Unstoppable allows organizations to be completely compatible with Section 508 needs. It allows full integration with the JAWS screen reader software and expands Jira and Confluence accessibility. By using text-to-speech technology, it is capable of reading out attributes to the user for them to take action - thereby helping them to work more efficiently with Jira and Confluence. Navigation is made simpler using intuitive keyboard strokes. JAWS shortcuts give users complete control and ably pinpoint the actual tasks at hand. It is also completely compatible with HTML5 entities.
As a result of its capabilities, the solution can drive productivity and reduce the stress of visually impaired developers and make their day to day activities easier and promote collaboration within the team.
Given the spotlight on Section 508, organizations must pay close attention to the design and development process and focus on human-centered design. For this, the accessibility needs of the users shouldn’t be seen as an impediment or constraint towards a good design. And it definitely should not be an afterthought.
Requirement Gathering: This means accessibility has to be taken into consideration right from the process of requirement gathering. To build an accessible application, it also means “exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives” says the Digital Services Playbook. It thus makes sense to keep the user at the center of the product and spend time with existing and prospective users of the product and service to evaluate their needs comprehensively.
Application Design and Development: The application design involves understanding how people with disabilities interact with the product/service, consider the actions they will take online and via mobile, identify the accessibility challenges in the same, and then move to the build process. It is also essential to ensure a simple and intuitive user interface, especially in the case of government agencies, to make sure that the users, irrespective of their accessibility needs can succeed in their tasks in the first attempt.
Continuous Testing: DevOps is a process that demands continuous testing. Accessibility testing becomes a lifesaver here to find and correct accessibility issues. Ensuring continuous accessibility testing and testing early provides the capability to save valuable time and money. It helps in capably identifying and remediating accessibility concerns before releasing the code to the test team.
Pushing accessibility testing to the end of the cycle also means greater effort to implement change because it can be hard to make features accessible once they have already been built. This can severely impact development velocity.
Incorporating accessibility testing as a subset of usability testing and shifting accessibility testing further left in the development cycle helps in enhancing quality without compromising on velocity. Because the sooner an accessibility issue is fixed, the less likely it is for them to get baked into the software, making them harder and more time-consuming to undo. Clearly, implementing 508 checks within the development cycle makes more sense than conducting one 508 test at the end.
DevOps teams today are obsessed with velocity and maintaining exceptionally high-levels of software quality. However, this can no longer be achieved at the cost of accessibility – both during and after development.