As a Delivery Manager you need to make sure that accessibility is considered when sizing up stories and that every feature is fully accessible before it is released.
If your team is unsure on how to test for accessibility, you can read more on how to do accessibility testing.
As the Product Manager, it is important that each member of the team takes responsibility for delivering an accessible service.
Everyone on the team has a role to play to make sure accessibility is considered and implemented at every phase of the project.
Often, there is a misconception that accessibility is a technical requirement and only affects developers and testers, but this is simply not true.
Make sure accessibility is covered in ceremonies such as sprint planning and sprint review, so the team know what considerations they must make and whether the delivered feature meets the standards.
Make sure that the team understands what content is in scope of legal requirements around accessibility, including documents hosted on your service.
If your team is unsure on how to test for accessibility, you can read more on how to do accessibility testing.
When writing user stories, we outline criteria for when they are ready to build. This is usually when it’s been through usability testing and the acceptance tests have been defined. But these discussions should also include accessibility.
As part of the stories definition of ready, make sure the team have discussed how the proposed design can be made accessible, and include important content in the story such as page titles and URLs as these can affect accessibility.
Work with an Interaction Designer and a Content Designer to understand which parts of the service might be tricky to build, for example things which do not exist already and will need to be built from scratch. These will require more testing.
An example of accessibility considerations in a definition of done:
As a product owner, you're responsible for ensuring accessibility is part of the definition of done and is planned, prioritised, and resourced appropriately across the team.
Checklist:
include accessibility in the team’s definition of done
ensure user stories include accessibility requirements where relevant
prioritise fixing accessibility issues alongside functional bugs
plan for accessibility testing in sprint activities
ensure designs, content, and development consider accessibility from the start
support the team in reaching WCAG 2.2 AA compliance as a baseline
keep the accessibility statement up to date when features change
engage with users with disabilities during research or testing phases when possible
Before anything can go live it needs to WCAG compliant or you’ll be breaking the law. This includes your Minimum Viable Product (MVP). You can’t go live and implement accessibility at a later date.
When estimating how long something will take to build, you will need to factor in sufficient accessibility testing. It should include automated testing, manual testing against the WCAG criteria, and usability testing using assistive software.
When doing releases, it is also important that the accessibility statement is updated. This needs to reflect when the service was last tested and any potential barriers that have been found or fixed.
If you do not plan for accessibility then it could create large amounts of technical debt and could significantly delay your releases.
Any team will develop it’s own culture overtime. It’s beliefs and priorities will be moulded by the way things get done from week to week.
If you de-prioritise accessibility then it becomes acceptable to the team to keep doing so, because it’s easier. As the Product Manager you need to ensure this does not happen.
By prioritising accessibility from the very start, it just becomes part of the culture of the team, and part of the process. This will allow you to deliver at pace and meet your legislative requirements, rather than accessibility becoming a bottleneck or a blocker.
Accessibility is often an expense which is not considered until it’s too late.
It takes time to develop and test for accessibility, and you may need an external audit before you can go into public beta. These time constraints and expenses will need to be communicated to stakeholders throughout the process so that it’s part of their expectations.
Make sure accessibility is budgeted for in both time and money, and does not simply get forgotten about.
As a Product Manager you need to understand the risks of building a service which is not accessible.
If your service is not accessible, then you won’t be able to pass a Beta assessment. But even worse, if you put a service live and it’s non-compliant, the service can be reported to the Equality and Human Rights Commission.
As the Enforcement Body the Equality and Human Rights commission has the power to issue enforcement notices, do investigations and even take court action against the department.