Mostly in my experience, most of these categories of people don't really care for the empathetic viewpoint of making platforms accessible. I am from Nigeria and the Laws don't "make" us implement accessibility in applications, unlike some counties where you can get sued. Which is also a valid reason for Implementing accessibility. However, I have successfully explained to stakeholders of products that if you create a platform that is accessible you have created an opportunity to get more uses and more users === more $$$.

Regardless making Accessibility important is super important. Imagine making something that everyone can use. It is brilliant.

The same way we got buy-in for test suites! Accessibility isn't a feature. It is the feature. Testing prevents bugs. Accessibility testing is no different. It prevents bugs.

If someone was unable to get through the purchase process, you'd be hot-fixing that so fast that heads would spin.

Why is it different when someone with a disability can't get through the purchase process?

#a11y issues are not optional features. They are bugs.

For designers, and developers, make it easier to do the right thing than to do the wrong thing. Implementing linters, and CI testing can be the first step. Developers fix lint errors, and test suites all the time. Tests associated with accessibility should be no different.

There are business people that need an ROI to support accessibility.

More users!

• 1 in 5 people have some sort of disability (World Health Organization)
• 1 in 10 websites are accessible (deque)

If your website is accessible, you could be cornering the market for those with disabilities!

More clients!

• Many governments require accessibility certification of not only government websites, but also companies working on government land, or contracting with the government.

Being accessible opens your business up to government entities

Lawsuits are expensive

The Dominos lawsuit in 2019 set a precedent, at least in the USA, that websites, even without government contracts, need to be accessible. People can sue your company! The smaller the company, the higher the risk of going bankrupt over an accessibility issue that could have been prevented.

supremecourt.gov/orders/courtorders/100719zor_m64…

Personal experience

We have an emotional response when we can relate accessibility with someone we know. Make it personal.

As 1 in 8 men are colorblind, chances are, there is a man in your company that is colorblind. Take that person to your boss and say, "Can you explain to {name of person}, who works for our company, why he doesn't matter enough to make our site accessible?"

The other answers have expressed a lot of great ideas! My only addition is:

Tap into the fears, motivations, and excitement from the key stakeholders and present the perspective that will be most relevant to them.

While we can be idealistic and want people to care for the most marginalised people in the world, frankly, not everyone does, particularly people at the top who might have made their success by way of exploiting people.

Some folks disagree and think that using finances as a motivation is problematic. I agree. And also, I personally care most about outcome. So if I'm working with someone who has shown me very clearly they don't care about people, but they care about money, I'm going to use that motivation in order to make the product as accessible and equitable as I can.

The outcome is that the product is more accessible and equitable, which is the end goal I always keep in sight.

Different approaches for different folks.

• Some people will be convinced by Moral Responsibility.
• More will be convinced by obvious business gains e.g good #a11y practices often translate to better SEO.
• Others are motivated by fear of litigation. No business owner wants to be sued.

However, I have noticed most people who seem to not care about #a11y are just indifferent. In their minds, they're choosing between #a11y and something else that's "more important". To make a change here, you need to demonstrate that it's not a zero-sum game. Accessibility and company/team goals aren't mutually exclusive. e.g I once told my PM that it'll take the same time for me to implement a feature accessibly as it would take to implement inaccessibly. Then, I went on to deliver. Gradually, the team accepted accessibility as a product requirement.

As a teammate, the best way to seek buy-in is to show that it can be done at little or no cost.

In my other answer, I shared how to engage folks and make accessibility a team-wide responsibility, so I hope those insights can be helpful here!

Something that has worked for me is to just start talking about accessibility and asking questions that presume accessibility is a core part of our process. It's not a niche discussion, it's the discussion.

• Has this form we're introducing been keyboard tested?
• Have these designs been checked for colour contrast?
• Where will be writing the alt text in? The copy deck?

Cultivating a culture of accessibility where it becomes habit is critical, where your teammates feel empowered to contribute and to help, rather than under the careful watchdog.

For writers, I've found tapping into their expertise and usually common desire to want things to be clear.

• Hey! I'd love your insights on h tags and how that impacts content order. If I provide you some context for how h tags work, could you label your copy doc?
• The alt text here hasn't been written. I'd love for it to be written by someone with your expertise!
• This form lacks guiding error messaging and I think its a place where our voice and tone can be really powerful. Could we work together to ensure we make warnings that are on brand?

For developers, I've found tapping into their desire for consistency and reuse:

• What can I do to make your job easier? [Reason for this question: A lot of the time I've found (and this is coming from a designer) that we don't do our own due diligence to make our designs accessible, so we're just passing that accessibility problem downstream. If your team is doing that work, awesome, and maybe share that work and care you put into it so that they feel like equal partners and stewards in ensuring your product is accessible]
• I've made the padding specific so that it's more accessible for touch for limited mobility especially. How can we permeate this padding system into our design system?
• What automatic testing and linting tools can be implement to make this easier on you?
• Making this element semantic would make it more accessible by default!

I think it can be helpful to point blank ask people: Do you care about making our product accessible to people? Figuring out that baseline first tends to help.

A little over a year ago, I started my accessibility crusade at Andela and the developer community in Lagos. In what is probably best described as accessibility harassment, I started out doing free accessibility testing, reviews, and feedback. Every time I had to unblock someone on a problem, they got an accessibility audit. I made several twitter threads on accessibility, low-hanging fruits, and inclusive thinking. After one year of crusading, I have good news, a number of developers and designers have been won-over to the accessibility-first camp. They are not experts but they're making an effort, moving us one step closer to a world of accessible products.

What I have learned.

• Consistency is key.
• Helping people achieve small victories motivates them to do more.
• There are different approaches to winning people over. Some will be moved by moral responsibility. Others will be moved by business value e.g good #a11y practices often translate to better SEO.

My favourite accessibility victories are any interaction where someone responds to how to make something more accessible with excitement and a desire to learn how to work together to do that.

Most of the time, unfortunately, accessibility is met with a wall: "Why do we care about this? It's only X percentage of users." So, whenever a team seems keen to figure things out (even if they lack much knowledge around accessibility), I consider that a win.

The next step/prospective win is figuring out how to empower the team so that accessibility isn't my singular cross to bear, but something that's discussed when I'm not around. I find it to be a win when colleagues install accessibility tools into their workflow or share that they checked something with a screen reader or even asked during a meeting "How does this decision impact the accessibility of the product?"!

A personal win is that I spent most of this week learning about how to make complex tables accessible. It's really a clear demonstration of how it's far simpler to make the content accessible first by reducing complexity of the table, then with what we're left with, figuring out how to lightly sprinkle necessary aria and visuallyhidden attributes to ensure the data is presented in the most thorough way for as many people as possible.

A PM once asked "Segun, how long will it take to build this page if we didn't care about accessibility". I responded "the same time it'll take to make it accessible". I went on to deliver and the team made accessibility a product requirement.

Yes! Accessibility is too often structured as a niche focus or working group within teams. Instead, accessibility needs to be thought of laterally. It is something that every single team member can positively impact at every single stage of the project.

Content strategists hold a huge role in structuring content in a clear, digestible manner:

-- Content structure's impact on how the body of a website is structured with <main>, <article>, <aside>, for example -- How content headers is processed through screenreaders via h tags. (I find educating writers on this so they have opinions about it! Some writers I've worked with would label their copy decks with it, which is supremely helpful!) -- Teaching them the parameters of alt text, table summaries, etc, so that their approach to content is holistic.

Designers hold a huge role in visualising and structuring the content in a perceivable manner from the start:

• Colour palette direction and testing which colour combinations meet contrast ratios from the start, including this in the system so that future design system contributors/users are invited to think about this from the onset.
• Typography direction; baking in styles and sizes that are flexible when someone zooms in
• Reliance on visual indicators: Designers tend to love reductionism, as clean design is prioritised, so they'll rely on an icon or colour alone to visualise something. Teaching them how to stress test elements so that they work for someone who is colour blind or for a screenreader user who will not see certain elements is critical.

Product managers and owners place a huge role in ensuring accessibility is considered at all phases of the project by all project contributors:

• Building accessibility as a core acceptance criteria rather than nice-to-have, which is ensuring true inclusion
• Priotising testing strategies are in place with real users!
• Introducing accessibility to all project contributors and educating key stakeholders on its importance.

Customer service and test/support engineers have a huge role in taking in accessibility feedback from real users, which checks if theory is operating in practice:

• Empowering these folks to close the feedback loop so that real user data makes its way into future releases
• Ensuring their front-line feedback is heard by key stakeholders is critical; often their voices are the least supported in an org (from my experience.)

There are of course more disciplines that beyond this! The general principle is that everyone has a critical role in making products more accessible at every juncture!

Designers and developers are the two disciplines that are bringing the product into being and therefore shoulder the burden of being the de facto advocates, but accessibility is everyone's job.

From the first idea of a product to the end-user who runs into an issue, we should all be mindful of how our products impact others, particularly those under stress. It takes leadership buy-in, manual testing from all the disciplines, and the willingness of ourselves to advocate for a more user-friendly experience.

One of the easiest ways to see this is to have a diverse and inclusive company that brings those other perspectives to the forefront. If that isn't currently the case in your company, creating personas with various limitations can be helpful. Try to see the product through the experience of someone else, and help others understand that impact.

⚠️ Caveat: Context is very important for accessibility, so I'm going to ask some questions before I provide an answer. So that this answer still provides helpful info until you answer, I'll provide some context-less recommendations in the meantime.

Questions

• Why is the text rendered as images?
• Why does the user need to tab to these specific parts? (What action do they need to take once they tab?
• What platform is this on/using what tech?
• What testing are you conducting?

General advice

• IMHO adjusting tabindex and manipulating tab order manipulation should be something we avoid as much as possible and use as a last resort. Once you force a certain tabindex, you are overwriting the natural flow, which can make things an ordered mess. So, again, without context, here, I would want to make the text live instead and not manipulate its focusable state (as most text isn't focused in flow unless it's a link or button or something interactive like that).
• Text rendered as images should use alt-text instead of aria labels for the most part to describe its content.
• Any images that are vector can usually be rendered as SVG instead, which will allow exposing of <text> elements.
• Generally speaking when we open the can of worms of manipulating focus, tab, and trying to make non-interactive elements interactive, we are fighting against the native behaviour of elements. We will then have to fight with our technology to do what we want, and as assistive technology is very inconsistent, it's going to be difficult to test to know how it works (and if it works) for those various technologies.

It is an Articulate eLearning module. There are many issues with it, but as I work with the eLearning developers to remediate them, I want to be clear about why making non-interactive elements tabbable is inappropriate. I am assessing the modules using Accessibility Insights Tatiana Mac

Matt Kreiling Thanks for that context! Great to hear you have an accessibility checker.

I think that it would be helpful to test the module with various assistive technologies to show how the screenreader will read the information and how a keyboard will navigate it (if you're not doing that already). Most of the time, the user should not have to tab to the element in order for it to be read—and keyboards are more than tab. Focus should be reserved for when the user needs to interact with that element, like links and opening closing modules.

Generally speaking, if you're using semantic markup, the correct elements will be focusable and the reading/tab flow will be handled by going in linear order, which is expected and good. I don't use Accessibility Insights myself so I'm not sure if it has a feature that can visualise the tab order for you, which I find helpful if I ever am forced to manipulate.

I hope that helps? Happy to answer any specific questions with more context as I can.

Starting with tools like Lighthouse or the aXe Firefox and Chrome extensions are great ways to start testing and gaining knowledge about what issues your site is experiencing, and ways to fix them.

When getting started with screen reader testing, you'll need a list of keyboard shortcuts and gestures. Keeping these close at hand will help you learn and get used to navigating your app.

It'll take some time to ramp up, and you won't become accessible in a day. Be kind to yourself and your team, and keep at it. Every fix helps.

I think that using testing software, accessibility standards and guidelines is an excellent place to start! Setting accessibility criteria as part of our acceptance criteria is critical to ensuring our design intent makes it all the way to the finish line and has positive impact on how accessible our product is.

However, I caution us to not use the metrics those platforms provide as our end-all-be-all.

For example, a lot of folks will chase 100 percent on Lighthouse and be done. Manuel Matuzovic wrote an article on making a site with 100 score that was inaccessible.

Accessibility should be thought of something that we're constantly trying to improve; so setting an end threshold is dangerous.

On the flip side, I think that it means we can constantly make consistent, incremental change to improve our accessibility with each snippet and sprint.

Broadly I think that thinking of the next billion users, we should focus our attention on the people that will be the most harmed by automation, global climate crisis, and the digitisation of basic needs. A core part of accessibility is...access. As we approach 5G, we will start to build for 5G, but most of the world isn't on 5G. We have to be mindful of how going cashless and prioritising tap payment or using only digital means to vote is going to exclude people who systematically don't have bank accounts or must use cash for various reasons.

That, to me, is the guiding light of access that we must always prioritise: The billions of people who are least benefitted from the tech we build and most harmed by it.

Bolaji Ayodeji

Start by making sure you're using Semantic HTML. Automated tools can often flag errors here. Things get tricky when you have complex widgets e.g tabbed UIs, autocomplete combo boxes. For such widgets, follow the WCAG prescription for expected behaviour, ARIA-attributes and keyboard interaction. Following the guidelines should be enough to provide the proper signals to assistive technologies. These tools know how to interact with these standard widgets.

What should you test?

• See this chat for some testing considerations.
• Learn how to use a screen-reader and test your application with one.
• Tab around to see how much you can do with the keyboard. Switch users often benefit from a site that's designed to be keyboard-friendly.

Accessibility doesn't only apply to web development, it actually spans every aspect of life 😊. You can check this out to learn about accessibility in android development developer.android.com/guide/topics/ui/accessibili…

No, it doesn’t. It applies to all areas of human interaction, not just software. In the area of software accessibility however, all mainstream platforms/operating systems have a built-in accessibility framework as well as primitives for building accessible software. We can take advantage of this. To learn more about android accessibility, start here: developer.android.com/guide/topics/ui/accessibili….

A quick google search for “[platform or OS] accessibility framework” should get you relevant resources on your preferred target.

No! Accessibility does not just apply to web development! It applies to everything we build. For all builders, I recommend understanding the core principles of accessibility so that you have a solid understanding of the theory behind what makes something accessible to the most people possible.

Core principles like colour contrast, semantic labelling/guiding text (content descriptions), motion considerations, media accessibility (captioned videos, etc) apply to all platforms.

Specific to Android dev, a good starter resource is Android's accessibility page.

Questions specifically I'd ask for Android and touch apps in general

• How is this being presented to a screenreader user?
• How precise are the touch movements I'm asking the user to make (especially for folks with limited mobility)?
• How much animation and motion am I using? How can I start with no motion so that the message is still conveyed if someone has reduced motion settings turned on?

The idea of web accessibility is to make web content available to as many people as possible irrespective of their disability status. If the content is a photograph. It's accessible to people who can see, but those who can't see still needs the information conveyed by the image. That's why we use alt text. What of video content? We have 2 points of exclusion here – vision and audio. We can use closed-captioning to complement the audio. We can also have a transcript available.

It's important to note that disability is a spectrum and people fit in different parts of that spectrum.

Media accessibility has is concerned with the more visual aspect of accessibility. It focuses on what people see, understand, and uses. So using the right colors for example, so that people with visual impairments(color blindness, achromatopia, etc. ) Can navigate your platform while understanding what's going on. Essentially how the human eyes can play a role in disabilities and how we can make a better web experience. I have done a talk about this drive.google.com/open . Please check it out. It offers some insight on how you can understand and implement Media Accessibility

By media files, I am guessing you mean images, videos, audio. (Will edit my answer if you mean something else).

Image

• Minimising and compressing file size, serving up responsive images in modern formats based on size needed So, if someone is accessing from a small phone, serve them up the smallest possible image while still ensuring integrity. (Fun two-fer, this is also excellent for performance, which also improves access as it mitigates bandwidth/data usage!)
• Adding alt text / figure captions and learning how to write them concisely (one small example, excluding "Image of"
• SVG accessibility Ensuring proper titling and use of <text> for any embedded text
• Understanding the difference between content and decorative elements some images are purely decorative and can exclude alt text, for example (using alt="")

Video

• Including captioning so that any spoken text is documented in an accessible way. If you're using a hosting platform, I would check with how they implement captioning. Some places like YouTube even have an auto-captioning service. (Be cautious when you use this to check as a real human, but the initial results have been pretty good from my experience!)
• Understanding the difference between open and closed captioning (generally, closed captioning, which is not permanently burned onto the video is better, as it can adjust for language adaption, for example. Open captioning is a helpful last resort for platforms where CC isn't yet supported, like TikTok or Instagram)
• Including and understanding audio description, which describes visual scenes so that anything conveyed only visually is announced
• Including transcripts for people who cognitively or situationally process that information better

Audio accessibility is similar, but removes the dimension of captioning and audio description.

Lastly I would say that accessibility also includes data and bandwidth restrictions. Our tendency in tech is to centre powerful high-end computers and phones, but most of the world is operating on much different equipment and many folks pay by data.

• Avoid auto-play or download of media (especially for things like chat apps, where people will send more media).
• Compress media as much as possible
• Append size of media files with file links, for example, [Video file, 23,5 M]

Hopefully that gives you a start to do more research! 🤓

Hi Bolaji, In my opinion. Implementing accessibility isn't necessarily "hard" and it is taught in the basics. When you think of it the bases of accessible apps start with semantic HTML (HTML5). I personally learned HTML5 without knowing I was learning to make accessible apps. I think maybe if that was pointed out with the importance a lot of people would be conscious about it.

Thanks, Bolaji.



The reason accessibility hasn’t made it into most coding tutorials is because the authors of such content mostly do not have limiting disabilities, therefore it’s easy to ignore needs that do not affect them. This doesn’t mean they’re evil, it’s just human nature. We tend to focus on things that affect us. I dare say a blind web developer wouldn’t create web content that excludes screen reader users.

This is why we must embrace an INCLUSIVE approach when designing/building software. It is possible to build a technically accessible product that is barely usable because it was not designed for inclusion. For example, giving every item on a website a positive tab-index makes it technically accessible to tab/switch users but not inclusive. Actually, that would be frustrating to these users because that’s not how they interact with pages. They expect to jump through a handful of focusable elements, not spend their entire day tabbing through every item on the page.



Do I think this is changing? Yes, thanks to the advocacy being done by people like Jen, Tatiana, Obinna, and many other accessibility experts in the community. There’s still a long way to go but we’re seeing progress.

I think that accessibility is not included into fundamental courses because the industry in which we work and the society in which we live systematically focuses its attention on the majority, and operates under an inherently ableist model. The majority tends to be able-bodied and neurotypical. Able-bodied and neurotypical people build things that work for them. People who are disabled and neurodivergent are excluded systematically at the top tier of every single system, which trickles down.

So, when we build technological systems that interface with banking systems, we're fighting against two systems that were not set up to include all. The education of building tech and banking systems is also intrinsically not accessible. Inaccessible systems compound other inaccessible systems, and exclude how to make things accessible for all.

What can we do about it?

• We can start infiltrating our educational systems, encouraging atraditional systems in particular (e.g., self-taught folks, code bootcamp students). I try to spend time visiting (by video these days) university courses for designers and developers, teaching them to think about accessibility first.

• Speaking about accessibility more and making it an acceptance criteria rather than nice-to-have in all of our projects.

• Daring to do things differently. Part of what perpetuates an unjust and inaccessible system is that we are complicit when we don't question why things are inaccessible.

• Showing our colleagues across all disciplines how their roles impact accessibility (content strategy which impacts h tags and content structure; designers how colour palette choices impact downstream contrast, etc)

• Trusting and centring disabled people who are most impacted by inaccessible technology. Putting them in power and holding space for them as core users of our products.