Why this matters
Product owners determine requirements, calculate the value and effort required to add new features and decide on the sequence and prioritization of work to be done.
If a product owner can’t commit to building accessible products, their design and development teams won’t be able to commit either.
Team commitment KPIs
What requirements must the team agree to meet if your organization is going to be successful?
These key attributes let you know a team has been educated and is ready to participate in an accessibility compliance program.
Can explain why accessibility is a requirement
There are a lot of ways to explain the benefits of accessibility, especially if product owners are hesitant to adopt it or view it as a cumbersome requirement.
Team members can possess varying levels of technical understanding, but all should be alert to the basic reasons accessibility is a requirement.
Accessibility target policies
At a minimum, any team needs to understand accessibility targets exist, are defined by enterprise policy and enforced by leadership.
This bare minimum adoption achieves some level of compliance, even when it’s begrudging.
However, if the reasons for accessibility policies are taken to heart in service of the customer, products can dramatically improve.
Living your organization’s values
Accessibility isn’t just the right thing to do, it’s the smartest thing to do.
Every organization has a set of values, often including core ethical tenets like treating people with respect and doing the right thing.
How does accessibility fit those values? How does ignoring accessibility breach them?
A tool for innovation
Accessible design and development builds better products for everyone. When teams put accessibility at the beginning of their processes, they create more valuable products for your enterprise.
26% of the US population has a disability that requires accommodation, making people with disabilities the largest minority in the United States. This adds up to billions of dollars in combined purchasing power.
Avoiding legal risk
Accessibility is the law. Designing and building accessibility into products also helps the enterprise avoid legal risk and liability due to a customer complaint.
Adds feature specific accessibility acceptance criteria
Developers will need specific testable criteria to hold them accountable.
Product owners can use MagentaA11y.com to generate acceptance criteria and simplify the process of accessibility testing.
It’s an intuitive way for product teams to define “done” in a way that ensures accessible experiences work for everyone.
Attends design reviews
Product owners and managers must attend design reviews, preferably with a senior design systems team. While the design system team exists to support the success of products, it also enables designers to make the best choices for the customer.
What happens when product owners don’t participate
When feedback is given from the design systems reviews solely to the designer, it quickly becomes problematic. Not every designer is comfortable with or articulate in standing up to their management team.
Accepts guidance from design reviews
Product owners and managers must be willing to attend and accept guidance from design systems reviews. The design system team will be advocating for the best customer experience and taking accessibility into account.
Facilitates use of design annotation for developers
Communication needs to be more than designers throwing design over the wall to developers. Designers can leave notes or even use a specific annotation kit to describe the experience for people using assistive technology.
Expects product demos with assistive technology
Create the expectation for teams to demo features with assistive technology. This reinforces the importance of accessibility to the organization and doesn’t allow teams to hide from requirements.