Accessibility at all stages: A Good-for-All SDLC approach
Aditya Bajaj is an Operations Manager focusing on accessibility and web operations at Microsoft.
We believe accessibility is essential to our industry—and the progress of all people. Implementing accessibility end-to-end is still challenging and has a lot of room for improvement in terms of efficient accessibility testing tools and processes. We are continuously looking for efficient tools and processes that help reduce the manual work and improve the overall accessibility of web, products, and services.
In the first half of 2019, my team worked on incorporating accessibility at all stages of our website development and maintenance lifecycle. Considering accessibility early-on helps minimize the churn between designers, developers, and QA. Hence, we trained and equipped our people with accessibility tools and resources. For any net new development, accessibility is considered at every stage from kick-off to design to development to post launch and maintenance. This approach reduces the number of bugs as the product progresses through various stages of its lifecycle. For example, for HoloLens 2 and Microsoft Build web sites, we were able to reduce number of accessibility violations early on and avoid the bolt-on approach to fix accessibility after development which is often more expensive and doesn’t consider all audiences. We saw 50% fewer accessibility bugs through this approach. We shared this learning at a high level at the 2nd annual Ability Summit Community Day event in May 2019 that was open to public.
Common accessibility issues we observed
Here are the common web content accessibility guidelines (WCAG) issues we observed in the design and content update phases. Paying special attention to these issues in the respective stages can help you reduce your accessibility bugs even further and improve your team’s efficiency in creating more usable web, software, or services.
In design phase
|
In content update/maintenance phase
|
We all know that accessibility improves usability; considering accessibility reviews early-on and at all stages gives us an opportunity to not only save cycles of design, dev, and QA, but more importantly, it creates a more usable product for everyone. Additionally, while automated QA for accessibility is not enough, it can still help make web pages and/or software accessible faster. Instead of running full manual assessment which can be time consuming, if accessibility issues found through automated checks are fixed first, it can also reduce total number of bugs found through manual assessment.
Accessibility testing tool
Step back and re-evaluate your team’s processes to ensure accessibility is considered early on. The free Accessibility Insights for Web browser extension available for Edge and Google Chrome helps you identify issues through automated as well as manual assessments. I like that the detailed step-by-step accessibility testing guidance on this tool can help anyone learn accessibility testing and overall about accessibility. The following key features of the accessibility insights tool are used the most in my team. The tab stops and no color simulation under “ad hoc” tools come handy too.
FastPass – the tool identifies instances and evaluates them automatically giving you visual mappings as well as an easy way to copy the issue details for your dev team to fix.
Manual assessment – the tool provides instructions for identifying and evaluating instances.
Reporting – at the end of assessment, you can generate a report quickly for your management teams to understand percentwise or technical teams to get the details of any recorded failures.
Light
Dark
0 comments