How To Make A Strong Case For Accessibility<\/h1>\nVitaly Friedman<\/address>\n 2024-06-26T12:00:00+00:00
\n 2024-10-15T23:05:45+00:00
\n <\/header>\n
Getting support for accessibility efforts isn\u2019t easy. There are many accessibility myths<\/a>, wrong assumptions, and expectations that make accessibility look like a complex, expensive, and time-consuming project. Let\u2019s fix that!<\/p>\nBelow are some practical techniques that have been working well for me to convince stakeholders<\/strong> to support and promote accessibility in small and large companies.<\/p>\n.course-intro{–shadow-color:206deg 31% 60%;background-color:#eaf6ff;border:1px solid #ecf4ff;box-shadow:0 .5px .6px hsl(var(–shadow-color) \/ .36),0 1.7px 1.9px -.8px hsl(var(–shadow-color) \/ .36),0 4.2px 4.7px -1.7px hsl(var(–shadow-color) \/ .36),.1px 10.3px 11.6px -2.5px hsl(var(–shadow-color) \/ .36);border-radius:11px;padding:1.35rem 1.65rem}@media (prefers-color-scheme:dark){.course-intro{–shadow-color:199deg 63% 6%;border-color:var(–block-separator-color,#244654);background-color:var(–accent-box-color,#19313c)}}<\/p>\n
This article is part of our ongoing series<\/strong> on UX<\/a>. You might want to take a look at Smart Interface Design Patterns<\/a> \ud83c\udf63 and the upcoming live UX training<\/a> as well. Use code BIRDIE<\/strong><\/a> to save 15%<\/strong> off.<\/p>\nLaunching Accessibility Efforts<\/h2>\n
A common way to address accessibility is to speak to stakeholders through the lens of corporate responsibility and ethical and legal implications. Personally, I\u2019ve never been very successful with this strategy. People typically dismiss concerns that they can\u2019t relate to, and as designers, we can\u2019t build empathy with facts<\/strong>, charts, or legal concerns.<\/p>\nThe problem is that people often don\u2019t know how accessibility applies to them. There is a common assumption that accessibility is dull and boring and leads to \u201cunexciting\u201d and unattractive products. Unsurprisingly, businesses often neglect it as an irrelevant edge case<\/strong>.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n Mapping accessibility to the needs of a product, example by Booking.com. (Large preview<\/a>)
\n <\/figcaption><\/figure>\nSo, I use another strategy. I start conversations about accessibility by visualizing it<\/strong>. I explain the different types of accessibility needs<\/strong>, ranging from permanent to temporary to situational — and I try to explain what exactly<\/em> it actually means to our products. Mapping a more generic understanding of accessibility to the specifics of a product helps everyone explore accessibility from a point that they can relate to.<\/p>\nAnd then I launch a small effort — just a few usability sessions<\/strong>, to get a better understanding of where our customers struggle and where they might be blocked. If I can\u2019t get access to customers, I try to proxy test via sales, customer success, or support. Nothing is more impactful than seeing real customers struggling in their real-life scenario with real products that a company is building.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n New WCAG 2.2 Accessibility Guidelines, a poster by fine folks at Intopia<\/a>. (Large preview<\/a>)
\n <\/figcaption><\/figure>\nFrom there, I move forward. I explain inclusive design, accessibility, neurodiversity<\/strong>, EAA<\/strong>, WCAG<\/strong>, ARIA<\/strong>. I bring people with disabilities into testing as we need a proper representation of our customer base. I ask for small commitments first, then ask for more. I reiterate over and over and over again that accessibility doesn\u2019t have to be expensive or tedious if done early, but it can be very expensive<\/strong> when retrofitted<\/strong> or done late.<\/p>\nThroughout that entire journey, I try to anticipate objections<\/strong> about costs, timing, competition, slowdowns, dullness — and keep explaining how accessibility can reduce costs, increase revenue, grow user base, minimize risks, and improve our standing in new markets. For that, I use a few templates<\/strong> that I always keep nearby just in case an argument or doubts arise.<\/p>\nUseful Templates To Make A Strong Case For Accessibility<\/h2>\n1. \u201cBut Accessibility Is An Edge Case!\u201d<\/h3>\n
\u274c \u201cBut accessibility is an edge case.<\/strong> Given the state of finances right now, unfortunately, we really can\u2019t invest in it right now.\u201d<\/p>\n\ud83d\ude45\ud83c\udffd\u2640\ufe0f \u201cI respectfully disagree. 1 in 6 people around the world experience disabilities. In fact, our competitors [X, Y, Z]<\/em> have launched accessibility efforts ([references]<\/em>), and we seem to be lagging behind. Plus, it doesn\u2019t have to be expensive. But it will be very expensive once we retrofit much later.\u201d<\/p>\n2. \u201cBut There Is No Business Value In Accessibility!\u201d<\/h3>\n
\u274c \u201cWe know that accessibility is important, but at the moment, we need to focus on efforts that will directly benefit business<\/strong>.\u201d<\/p>\n\ud83d\ude45\ud83c\udffc\u2642\ufe0f \u201cI understand what you are saying, but actually, accessibility directly benefits business. Globally, the extended market is estimated at 2.3 billion people<\/strong><\/a>, who control an incremental $6.9 trillion in annual disposable income. Prioritizing accessibility very much aligns with your goal to increase leads<\/strong>, customer engagement<\/strong>, mitigate risk, and reduce costs.\u201d (via Yichan Wang<\/a>)<\/p>\n3. \u201cBut We Don\u2019t Have Disabled Users!\u201d<\/h3>\n
\u274c \u201cWhy should we prioritize accessibility? Looking at our data, we don\u2019t really have any disabled users<\/strong> at all. Seems like a waste of time and resources.\u201d<\/p>\n\ud83d\ude45\u2640\ufe0f \u201cWell, if a product is inaccessible, users with disabilities can\u2019t and won\u2019t be using it. But if we do make our product more accessible, we open the door for prospect users for years to come. Even small improvements can have a high impact. It doesn\u2019t have to be expensive nor time-consuming.\u201d<\/p>\n
4. \u201cScreen Readers Won\u2019t Work With Our Complex System!\u201d<\/h3>\n
\u274c \u201cOur application is very complex and used by expert users. Would it even work at all with screen readers<\/strong>?\u201d<\/p>\n\ud83d\ude45\ud83c\udffb\u2640\ufe0f \u201cIt\u2019s not about designing only for screen readers. Accessibility can be permanent, but it can also be temporary and situational — e.g., when you hold a baby in your arms or if you had an accident. Actually, it\u2019s universally useful and beneficial for everyone.\u201d<\/p>\n
5. \u201cWe Can\u2019t Win Market With Accessibility Features!\u201d<\/h3>\n
\u274c \u201cTo increase our market share, we need features that benefit everyone<\/strong> and improve our standing against competition. We can\u2019t win the market with accessibility.\u201d<\/p>\n\ud83d\ude45\ud83c\udffe\u2642\ufe0f \u201cModern products succeed not by designing more features, but by designing better features<\/strong> that improve customer\u2019s efficiency, success rate, and satisfaction. And accessibility is one of these features. For example, voice control and auto-complete were developed for accessibility but are now widely used by everyone. In fact, the entire customer base benefits from accessibility features.\u201d<\/p>\n6. \u201cOur Customers Can\u2019t Relate To Accessibility Needs\u201d<\/h3>\n
\u274c \u201cOur research clearly shows that our customers are young and healthy, and they don’t have accessibility needs<\/strong>. We have other priorities, and accessibility isn\u2019t one of them.\u201d<\/p>\n\ud83d\ude45\u2640\ufe0f \u201cI respectfully disagree. People of all ages can have accessibility needs. In fact, accessibility features show your commitment to inclusivity, reaching out to every potential customer of any age, regardless of their abilities.<\/p>\n
This not only resonates with a diverse audience but also positions your brand as socially responsible and empathetic. As you know, our young user base increasingly values corporate responsibility<\/strong>, and this can be a significant differentiator for us, helping to build a loyal customer base for years to come.\u201d (via Yichan Wang<\/a>)<\/p>\n7. \u201cLet\u2019s Add Accessibility Later\u201d<\/h3>\n
\u274c \u201cAt the moment, we need to focus on the core features of our product. We can always add accessibility later<\/strong> once the product is more stable.\u201d<\/p>\n\ud83d\ude45\ud83c\udffc \u201cI understand concerns about timing and costs. However, it\u2019s important to note that integrating accessibility from the start is far more cost-effective<\/strong> than retrofitting it later. If accessibility is considered after development is complete, we will face significant additional expenses<\/strong> for auditing accessibility, followed by potentially extensive work involving a redesign and redevelopment.<\/p>\nThis process can be significantly more expensive than embedding accessibility from the beginning. Furthermore, delaying accessibility can expose your business to legal risks<\/strong>. With the increasing number of lawsuits for non-compliance with accessibility standards, the cost of legal repercussions could far exceed the expense of implementing accessibility now. The financially prudent move is to work on accessibility now.\u201d<\/p>\nYou can find more useful ready-to-use templates in Yichan Wang\u2019s Designer\u2019s Accessibility Advocacy Toolkit<\/a> — a fantastic resource to keep nearby.<\/p>\nBuilding Accessibility Practices From Scratch<\/h2>\n
As mentioned above, nothing is more impactful than visualizing accessibility<\/strong>. However, it requires building accessibility research and accessibility practices from scratch, and it might feel like an impossible task, especially in large corporations. In \u201cHow We\u2019ve Built Accessibility Research at Booking.com<\/a>\u201d, Maya Alvarado<\/a> presents a fantastic case study on how to build accessibility practices and inclusive design into UX research from scratch.<\/p>\nMaya rightfully points out that automated accessibility testing alone isn\u2019t reliable<\/strong>. Compliance means that a user can use your product, but it doesn\u2019t mean that it\u2019s a great user experience. With manual testing, we make sure that customers actually meet their goals and do so effectively.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n Universal design vs. Inclusive design vs. Accessible design. A visualization by Eugene Woo. (Large preview<\/a>)
\n <\/figcaption><\/figure>\nStart by gathering colleagues and stakeholders interested in accessibility. Document what research was done already and where the gaps are. And then whenever possible, include 5–12 users with disabilities in accessibility testing.<\/p>\n
Then, run a small accessibility initiative around key flows<\/strong>. Tap into critical touch points and research them. As you are making progress, extend to components, patterns, flows, and service design. And eventually, incorporate inclusive sampling<\/strong> into all research projects — at least 15% of usability testers should have a disability.<\/p>\nCompanies often struggle to recruit testers with disabilities<\/strong>. One way to find participants is to reach out to local chapters, local training centers, non-profits, and public communities of users with disabilities in your country. Ask the admin\u2019s permission to post your research announcement, and it won\u2019t be rejected. If you test on site, add extra $25–$50<\/strong> depending on disability transportation.<\/p>\nI absolutely love the idea of extending Microsoft’s Inclusive Design Toolkit<\/a> to meet specific user needs of a product. It adds a different dimension to disability considerations which might be less abstract and much easier to relate for the entire organization.<\/p>\nAs Maya noted, inclusive design is about building a door that can be opened by anyone and lets everyone in. Accessibility isn\u2019t a checklist<\/strong> — it\u2019s a practice that goes beyond compliance. A practice that involves actual people with actual disabilities throughout all UX research activities.<\/p>\nWrapping Up<\/h2>\n
To many people, accessibility is a big mystery box<\/strong>. They might have never seen a customer with disabilities using their product, and they don\u2019t really understand what it involves and requires. But we can make accessibility relatable<\/strong>, approachable, and visible by bringing accessibility testing to our companies — even if it\u2019s just a handful of tests with people with disabilities.<\/p>\nNo manager really wants to deliberately ignore the needs<\/strong> of their paying customers — they just need to understand these needs first. Ask for small commitments, and get the ball rolling from there.<\/p>\nSet up an accessibility roadmap<\/strong> with actions, timelines, roles and goals. Frankly, this strategy has been working for me much better than arguing about legal and moral obligations, which typically makes stakeholders defensive and reluctant to commit.<\/p>\nFingers crossed!<\/strong> And a huge thank-you<\/strong> to everyone working on and improving accessibility in your day-to-day work, often without recognition and often fueled by your own enthusiasm and passion — thank you for your incredible work in pushing accessibility forward! \ud83d\udc4f\ud83c\udffc\ud83d\udc4f\ud83c\udffd\ud83d\udc4f\ud83c\udffe<\/p>\nUseful Resources<\/h2>\nMaking A Case For Accessibility<\/h3>\n\n- \u201cHow To Make The Business Case For Accessibility<\/a>\u201d, by R Gregory Williams<\/li>\n
- \u201cHow We\u2019ve Built Accessibility Research at Booking.com<\/a>\u201d, by Maya Alvarado<\/li>\n
- \u201cDesigner\u2019s Accessibility Advocacy Toolkit<\/a>\u201d, by Yichan Wang<\/li>\n
- \u201cMaking The Case for Accessibility<\/a>\u201d, by Susanna Zaraysky<\/li>\n
- \u201cMaking A Strong Case For Accessibility<\/a>\u201d, by Todd Libby<\/li>\n
- \u201cAccessibility Case Studies and Success Stories<\/a>\u201d, by Deque<\/li>\n
- \u201cInclusive Design Toolkits and Templates<\/a>\u201d, by yours truly<\/li>\n<\/ul>\n
Accessibility Testing<\/h3>\n\n- \u201cA Comprehensive Guide to Accessible UX Research<\/a>\u201d, by Brian Grellmann<\/li>\n
- \u201cInclusive User Research: Recruiting Participants<\/a>\u201d, by Ela Gorla<\/li>\n
- \u201cTesting With Blind Users: A Cheatsheet<\/a>\u201d, by Slava Shestopalov<\/li>\n
- \u201cMobile Accessibility Research with Screen-Reader Users<\/a>\u201d, by Tanner Kohler<\/li>\n
- \u201cHow To Conduct UX Research With Participants With Disabilities<\/a>\u201d, by Peter McNally<\/li>\n
- \u201cHow To Conduct Accessibility UX Research<\/a>\u201d, by AnswerLab<\/li>\n<\/ul>\n
Meet Smart Interface Design Patterns<\/h2>\n
If you are interested in UX and design patterns<\/strong>, take a look at Smart Interface Design Patterns<\/strong><\/a>, our 10h-video course<\/strong> with 100s of practical examples from real-life projects — with a live UX training later this year. Everything from mega-dropdowns to complex enterprise tables — with 5 new segments added every year. Jump to a free preview<\/a>. Use code BIRDIE<\/strong><\/a> to save 15%<\/strong> off.<\/p>\n
<\/a>Meet Smart Interface Design Patterns<\/a>, our video course on interface design & UX.<\/figcaption><\/figure>\n
\n 2024-10-15T23:05:45+00:00
\n <\/header>\n
Below are some practical techniques that have been working well for me to convince stakeholders<\/strong> to support and promote accessibility in small and large companies.<\/p>\n .course-intro{–shadow-color:206deg 31% 60%;background-color:#eaf6ff;border:1px solid #ecf4ff;box-shadow:0 .5px .6px hsl(var(–shadow-color) \/ .36),0 1.7px 1.9px -.8px hsl(var(–shadow-color) \/ .36),0 4.2px 4.7px -1.7px hsl(var(–shadow-color) \/ .36),.1px 10.3px 11.6px -2.5px hsl(var(–shadow-color) \/ .36);border-radius:11px;padding:1.35rem 1.65rem}@media (prefers-color-scheme:dark){.course-intro{–shadow-color:199deg 63% 6%;border-color:var(–block-separator-color,#244654);background-color:var(–accent-box-color,#19313c)}}<\/p>\n This article is part of our ongoing series<\/strong> on UX<\/a>. You might want to take a look at Smart Interface Design Patterns<\/a> \ud83c\udf63 and the upcoming live UX training<\/a> as well. Use code BIRDIE<\/strong><\/a> to save 15%<\/strong> off.<\/p>\n A common way to address accessibility is to speak to stakeholders through the lens of corporate responsibility and ethical and legal implications. Personally, I\u2019ve never been very successful with this strategy. People typically dismiss concerns that they can\u2019t relate to, and as designers, we can\u2019t build empathy with facts<\/strong>, charts, or legal concerns.<\/p>\n The problem is that people often don\u2019t know how accessibility applies to them. There is a common assumption that accessibility is dull and boring and leads to \u201cunexciting\u201d and unattractive products. Unsurprisingly, businesses often neglect it as an irrelevant edge case<\/strong>.<\/p>\n <\/p>\n <\/a> So, I use another strategy. I start conversations about accessibility by visualizing it<\/strong>. I explain the different types of accessibility needs<\/strong>, ranging from permanent to temporary to situational — and I try to explain what exactly<\/em> it actually means to our products. Mapping a more generic understanding of accessibility to the specifics of a product helps everyone explore accessibility from a point that they can relate to.<\/p>\n And then I launch a small effort — just a few usability sessions<\/strong>, to get a better understanding of where our customers struggle and where they might be blocked. If I can\u2019t get access to customers, I try to proxy test via sales, customer success, or support. Nothing is more impactful than seeing real customers struggling in their real-life scenario with real products that a company is building.<\/p>\n <\/p>\n <\/a> From there, I move forward. I explain inclusive design, accessibility, neurodiversity<\/strong>, EAA<\/strong>, WCAG<\/strong>, ARIA<\/strong>. I bring people with disabilities into testing as we need a proper representation of our customer base. I ask for small commitments first, then ask for more. I reiterate over and over and over again that accessibility doesn\u2019t have to be expensive or tedious if done early, but it can be very expensive<\/strong> when retrofitted<\/strong> or done late.<\/p>\n Throughout that entire journey, I try to anticipate objections<\/strong> about costs, timing, competition, slowdowns, dullness — and keep explaining how accessibility can reduce costs, increase revenue, grow user base, minimize risks, and improve our standing in new markets. For that, I use a few templates<\/strong> that I always keep nearby just in case an argument or doubts arise.<\/p>\n \u274c \u201cBut accessibility is an edge case.<\/strong> Given the state of finances right now, unfortunately, we really can\u2019t invest in it right now.\u201d<\/p>\n \ud83d\ude45\ud83c\udffd\u2640\ufe0f \u201cI respectfully disagree. 1 in 6 people around the world experience disabilities. In fact, our competitors [X, Y, Z]<\/em> have launched accessibility efforts ([references]<\/em>), and we seem to be lagging behind. Plus, it doesn\u2019t have to be expensive. But it will be very expensive once we retrofit much later.\u201d<\/p>\n \u274c \u201cWe know that accessibility is important, but at the moment, we need to focus on efforts that will directly benefit business<\/strong>.\u201d<\/p>\n \ud83d\ude45\ud83c\udffc\u2642\ufe0f \u201cI understand what you are saying, but actually, accessibility directly benefits business. Globally, the extended market is estimated at 2.3 billion people<\/strong><\/a>, who control an incremental $6.9 trillion in annual disposable income. Prioritizing accessibility very much aligns with your goal to increase leads<\/strong>, customer engagement<\/strong>, mitigate risk, and reduce costs.\u201d (via Yichan Wang<\/a>)<\/p>\n \u274c \u201cWhy should we prioritize accessibility? Looking at our data, we don\u2019t really have any disabled users<\/strong> at all. Seems like a waste of time and resources.\u201d<\/p>\n \ud83d\ude45\u2640\ufe0f \u201cWell, if a product is inaccessible, users with disabilities can\u2019t and won\u2019t be using it. But if we do make our product more accessible, we open the door for prospect users for years to come. Even small improvements can have a high impact. It doesn\u2019t have to be expensive nor time-consuming.\u201d<\/p>\n \u274c \u201cOur application is very complex and used by expert users. Would it even work at all with screen readers<\/strong>?\u201d<\/p>\n \ud83d\ude45\ud83c\udffb\u2640\ufe0f \u201cIt\u2019s not about designing only for screen readers. Accessibility can be permanent, but it can also be temporary and situational — e.g., when you hold a baby in your arms or if you had an accident. Actually, it\u2019s universally useful and beneficial for everyone.\u201d<\/p>\n \u274c \u201cTo increase our market share, we need features that benefit everyone<\/strong> and improve our standing against competition. We can\u2019t win the market with accessibility.\u201d<\/p>\n \ud83d\ude45\ud83c\udffe\u2642\ufe0f \u201cModern products succeed not by designing more features, but by designing better features<\/strong> that improve customer\u2019s efficiency, success rate, and satisfaction. And accessibility is one of these features. For example, voice control and auto-complete were developed for accessibility but are now widely used by everyone. In fact, the entire customer base benefits from accessibility features.\u201d<\/p>\n \u274c \u201cOur research clearly shows that our customers are young and healthy, and they don’t have accessibility needs<\/strong>. We have other priorities, and accessibility isn\u2019t one of them.\u201d<\/p>\n \ud83d\ude45\u2640\ufe0f \u201cI respectfully disagree. People of all ages can have accessibility needs. In fact, accessibility features show your commitment to inclusivity, reaching out to every potential customer of any age, regardless of their abilities.<\/p>\n This not only resonates with a diverse audience but also positions your brand as socially responsible and empathetic. As you know, our young user base increasingly values corporate responsibility<\/strong>, and this can be a significant differentiator for us, helping to build a loyal customer base for years to come.\u201d (via Yichan Wang<\/a>)<\/p>\n \u274c \u201cAt the moment, we need to focus on the core features of our product. We can always add accessibility later<\/strong> once the product is more stable.\u201d<\/p>\n \ud83d\ude45\ud83c\udffc \u201cI understand concerns about timing and costs. However, it\u2019s important to note that integrating accessibility from the start is far more cost-effective<\/strong> than retrofitting it later. If accessibility is considered after development is complete, we will face significant additional expenses<\/strong> for auditing accessibility, followed by potentially extensive work involving a redesign and redevelopment.<\/p>\n This process can be significantly more expensive than embedding accessibility from the beginning. Furthermore, delaying accessibility can expose your business to legal risks<\/strong>. With the increasing number of lawsuits for non-compliance with accessibility standards, the cost of legal repercussions could far exceed the expense of implementing accessibility now. The financially prudent move is to work on accessibility now.\u201d<\/p>\n You can find more useful ready-to-use templates in Yichan Wang\u2019s Designer\u2019s Accessibility Advocacy Toolkit<\/a> — a fantastic resource to keep nearby.<\/p>\n As mentioned above, nothing is more impactful than visualizing accessibility<\/strong>. However, it requires building accessibility research and accessibility practices from scratch, and it might feel like an impossible task, especially in large corporations. In \u201cHow We\u2019ve Built Accessibility Research at Booking.com<\/a>\u201d, Maya Alvarado<\/a> presents a fantastic case study on how to build accessibility practices and inclusive design into UX research from scratch.<\/p>\n Maya rightfully points out that automated accessibility testing alone isn\u2019t reliable<\/strong>. Compliance means that a user can use your product, but it doesn\u2019t mean that it\u2019s a great user experience. With manual testing, we make sure that customers actually meet their goals and do so effectively.<\/p>\n <\/p>\n <\/a> Start by gathering colleagues and stakeholders interested in accessibility. Document what research was done already and where the gaps are. And then whenever possible, include 5–12 users with disabilities in accessibility testing.<\/p>\n Then, run a small accessibility initiative around key flows<\/strong>. Tap into critical touch points and research them. As you are making progress, extend to components, patterns, flows, and service design. And eventually, incorporate inclusive sampling<\/strong> into all research projects — at least 15% of usability testers should have a disability.<\/p>\n Companies often struggle to recruit testers with disabilities<\/strong>. One way to find participants is to reach out to local chapters, local training centers, non-profits, and public communities of users with disabilities in your country. Ask the admin\u2019s permission to post your research announcement, and it won\u2019t be rejected. If you test on site, add extra $25–$50<\/strong> depending on disability transportation.<\/p>\n I absolutely love the idea of extending Microsoft’s Inclusive Design Toolkit<\/a> to meet specific user needs of a product. It adds a different dimension to disability considerations which might be less abstract and much easier to relate for the entire organization.<\/p>\n As Maya noted, inclusive design is about building a door that can be opened by anyone and lets everyone in. Accessibility isn\u2019t a checklist<\/strong> — it\u2019s a practice that goes beyond compliance. A practice that involves actual people with actual disabilities throughout all UX research activities.<\/p>\n To many people, accessibility is a big mystery box<\/strong>. They might have never seen a customer with disabilities using their product, and they don\u2019t really understand what it involves and requires. But we can make accessibility relatable<\/strong>, approachable, and visible by bringing accessibility testing to our companies — even if it\u2019s just a handful of tests with people with disabilities.<\/p>\n No manager really wants to deliberately ignore the needs<\/strong> of their paying customers — they just need to understand these needs first. Ask for small commitments, and get the ball rolling from there.<\/p>\n Set up an accessibility roadmap<\/strong> with actions, timelines, roles and goals. Frankly, this strategy has been working for me much better than arguing about legal and moral obligations, which typically makes stakeholders defensive and reluctant to commit.<\/p>\n Fingers crossed!<\/strong> And a huge thank-you<\/strong> to everyone working on and improving accessibility in your day-to-day work, often without recognition and often fueled by your own enthusiasm and passion — thank you for your incredible work in pushing accessibility forward! \ud83d\udc4f\ud83c\udffc\ud83d\udc4f\ud83c\udffd\ud83d\udc4f\ud83c\udffe<\/p>\n If you are interested in UX and design patterns<\/strong>, take a look at Smart Interface Design Patterns<\/strong><\/a>, our 10h-video course<\/strong> with 100s of practical examples from real-life projects — with a live UX training later this year. Everything from mega-dropdowns to complex enterprise tables — with 5 new segments added every year. Jump to a free preview<\/a>. Use code BIRDIE<\/strong><\/a> to save 15%<\/strong> off.<\/p>\nLaunching Accessibility Efforts<\/h2>\n
<\/p>\n
\n <\/figcaption><\/figure>\n<\/p>\n
\n <\/figcaption><\/figure>\nUseful Templates To Make A Strong Case For Accessibility<\/h2>\n
1. \u201cBut Accessibility Is An Edge Case!\u201d<\/h3>\n
2. \u201cBut There Is No Business Value In Accessibility!\u201d<\/h3>\n
3. \u201cBut We Don\u2019t Have Disabled Users!\u201d<\/h3>\n
4. \u201cScreen Readers Won\u2019t Work With Our Complex System!\u201d<\/h3>\n
5. \u201cWe Can\u2019t Win Market With Accessibility Features!\u201d<\/h3>\n
6. \u201cOur Customers Can\u2019t Relate To Accessibility Needs\u201d<\/h3>\n
7. \u201cLet\u2019s Add Accessibility Later\u201d<\/h3>\n
Building Accessibility Practices From Scratch<\/h2>\n
<\/p>\n
\n <\/figcaption><\/figure>\nWrapping Up<\/h2>\n
Useful Resources<\/h2>\n
Making A Case For Accessibility<\/h3>\n
\n
Accessibility Testing<\/h3>\n
\n
Meet Smart Interface Design Patterns<\/h2>\n
<\/a>