post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

Sunday Rewind: Whose job is it anyway? The rise of Product Ops and why it deserves to be an independent function

Guest Post

Creating metrics that matter

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

Emily brings nearly 15 years of product management experience to her role as Managing Director for Mind the Product. While she has worked across a variety of industries, she will always have a soft spot for the travel industry where she spent most of her early career building software for airlines and developing a leading consumer travel app, TripCase. Emily is passionate about the craft of product management and loves talking about new ways to make products people love.

Managing Director

Emily Tate

Building accessible products is the right thing to do. In concept, this is not a difficult idea to agree with. As technology becomes more ingrained into everyday life, the ability to use digital products is a necessity; therefore, from an ethical perspective, ensuring that a diverse set of customers can use your product is a moral imperative.
There is also a real financial risk to not making your product accessible. In the US for example, the Americans with Disabilities Act (ADA) prohibits discrimination against disabled persons in the “full and equal enjoyment of public accommodations”. Simply put: everyone should be able to access your business without barriers. This is why businesses have wheelchair ramps, handicap parking spots, and bathroom stalls that are large enough to accommodate different mobility needs.
But the law was written before the digital era and is very unclear how this could be applied to digital businesses. <a href="https://www.adatitleiii.com/2017/08/two-new-york-federal-judges-refuse-to-dismiss-website-accessibility-cases/">Lawsuits against digital products have been filed under the ADA</a>, and while the precedents have not yet fully been set, there are signs that courts may take a broad interpretation of these regulations and apply the designation of “public accommodations” to many websites and online products. In addition, if your product may be used by the US Government, you are legally obligated to build for accessibility by <a href="https://section508.gov/content/learn/laws-and-policies">Section 508 of the of the Rehabilitation Act of 1973 (as amended in 1998)</a>. Similar regulation exists in the UK and the EU.
On the other hand, accessibility is scary. As a product manager, I am constantly being pressured to build more things at a faster pace, and hearing that there are additional requirements that I don’t fully understand but feel cumbersome can make “accessibility” feel like a monster in the closet, ready to jump on your back and slow the team down. It is far easier to bury your head in the sand, cross your fingers that your little product won’t attract enough attention to merit a lawsuit, and convince yourself that your product doesn’t need to think about accessibility &#8211; why would someone with disabilities want to use it anyway?
This is where I sat with a product I once managed. I led the product team for a travel app, during the time that the <a href="https://www.tnooz.com/article/airlines-online-accessibility-regulations/">US Department of Transportation issued rules</a> requiring all websites offering air transportation to be accessible. The mere concept of accessibility terrified me &#8211; I pictured my roadmap being blown up and all the strategic plans I had being pushed into future years as I spent my entire budget doing something for people that probably wouldn’t want to use my app in the first place. This was an ignorant view on many levels, but it was easier to sit in my ignorance than attempt to really understand what accessibility meant, why it was important, and how I could address it without killing all my goals.
<h2>Lessons Learned</h2>
My first client as a product management consultant forced me to face this issue head on &#8211; it was a government agency who was required to comply with Section 508 requirements. Along the way, I learned several important lessons about building for accessibility.
<h3>Accessibility is Not That Hard &#8211; If You’re Willing to Do It</h3>
My fear of accessibility ruining the ability to move forward in my roadmap was completely unfounded. To take an analogy from the physical space, building <a href="http://americanhistory.si.edu/blog/smashing-barriers-access-disability-activism-and-curb-cuts">curb cuts</a> into sidewalks is not a technically difficult solution to providing mobility for wheelchair users, but is completely life-changing for those who rely on them. This is the same for the digital space &#8211; ensuring your color palette complies with <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html" target="_blank" rel="noopener">WCAG 2.0 standards for contrast ratio</a> (4:5:1) is an easy action that means a visually impaired user can read your text. Using visual cues besides color to identify an error state is simple, and can ease the frustration of a color-blind user. Checking that your tab order is logical means a keyboard-only user can navigate your site. Making sure you properly add alt text to images takes very little effort, but opens up a new world for users who rely on screen readers. The list of small improvements that change your product from unusable to accessible is huge, and most are relatively easy to implement.
As a bonus: most of your “fixes” actually <a href="https://medium.com/@mosaicofminds/the-curb-cut-effect-how-making-public-spaces-accessible-to-people-with-disabilities-helps-everyone-d69f24c58785">make your product better</a> for the rest of your users as well!
<h3>Build Accessibility Into Every User Story</h3>
Now that you have decided to take accessibility seriously, as a product manager, the question becomes, how tactically do you make it happen? If you want to ensure accessibility is implemented properly, you need to write accessibility criteria into every user story.
As a user, I want to submit some information, so that I can accomplish a task.
Acceptance Criteria
Given: I am on a certain page
When: I click a button
Then: An action should occur
Keyboard Acceptance Criteria
Given: I am navigating the site using only my keyboard
When: I tab to the button
Then: I should see the button highlighted on focus
And When: I press enter on a highlighted button
Then: An action should occur
Screenreader Acceptance Criteria
Given: I am using a screenreader to navigate the site
When: I tab to the button
Then: I should hear the label of the button
And When: I press enter
Then: I should hear that an action has occurred
Does this make your stories longer? Yes. Can it make some stories take longer to build? Yes, but in the same way automated testing makes stories take longer to build. It is a part of building quality software and speeds the team up in the long run.
Even more important, you need to reject a user story if it doesn’t meet the acceptance criteria. At some point, you will have a story that passes the functional acceptance criteria (I click the button and it does what I expect) but fails the accessibility criteria (I tab to the button, but the screen reader doesn’t read the label correctly), and it is incredibly tempting to accept the story but “split out the accessibility stuff for the next iteration”. Don’t do this. If you, as the product manager, won’t take these requirements seriously, your development team likely won’t either. This will result in many accessibility requirements being “deferred”, and before long you have a big backlog of accessibility debt to tackle and users who can’t use your product.
In addition, if you try to separate out the accessibility criteria from the core story, you may find that you have designed yourself into a corner that can’t be built in an accessible way, and end up requiring rework. For example, you may design a complex workflow with intricate elements to complete a task. If you haven’t considered accessibility up front, you may discover that some of the elements are impossible to build for accessibility and end up having to redesign the workflow you just built. This slows you down far more than taking these requirements into account up front ever could.
<h3>Retrofitting for Accessibility</h3>
Like retrofitting a building for accessibility, retrofitting a product for accessibility can be tough and time-consuming. If you aren’t able to get the funding or time for a specific “make our product accessible” initiative, I recommend taking stock of all of the areas you need to address, and start pulling in a story or two per iteration, all while making sure that anything new you build is accessible from the beginning. This might look like having a story to fix your inaccessible error messages this iteration, and then prioritize adding alt text to all of your images in the next.  Another iteration might see you swapping out some flashing animations (potential triggers for epilepsy) for something more static. However, at some point, you may have to call out some bigger changes (e.g. navigation structures) and use your influence as a product manager to make them happen.
<h3>Don’t Reinvent the Wheel</h3>
At this point in the evolution of the internet, there are many resources and frameworks built for Web Accessibility. The <a href="https://www.w3.org/WAI/">W3C Web Accessibility Initiative</a> is a fairly comprehensive resource for accessibility information. Modern frameworks like <a href="https://material.io/design/usability/accessibility.html">Google Material Design</a> have accessibility built in. <a href="https://ebay.gitbooks.io/mindpatterns/content/">eBay</a> has worked closely with <a href="https://webaim.org/">WebAIM</a> to build an easy-to-comprehend guide to accessibility for those of us who are just getting started. And if all else fails, the answers you’re looking for are typically a web search or Twitter question away. Follow the established patterns and your product will be accessible in no time.
<h3>Advocate for ALL Users</h3>
As product managers, we sit at the <a href="https://www.mindtheproduct.com/what-exactly-is-a-product-manager/">intersection of business, tech, and UX</a>. From a UX perspective, this often means that we can be a voice for our users and design team when we’re talking to “the business” or development. Over the last few years, product as another advocate for users has become commonplace, and we have progressed into partnering with design to build products people love. But we’re still leaving out a large portion of the population if we don’t take our responsibility to advocate for all users seriously. Use your influence to drive accessibility in your organization, and build products that people love&#8230; and can actually use.
<h3>Further Reading</h3>
<a href="http://interactions.acm.org/archive/view/september-october-2018/putting-accessibility-first">Putting Accessibility First</a> by Elizabeth Churchill

core/freeform

Common transformation pitfalls by Marty Cagan

Using principles to make better decisions faster by Martin Eriksson

How to build for creators by Peter Yang

How to navigate tricky work relationships

Organizing around complex products at the intersection of physical and digital by Matthew Cornford

Building Accessibility in to Your Products: Just Do It!

Emily Tate

Read more

Comments