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.

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.

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.

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.

⚠️ 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.

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! 🤓

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?

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.

I got started in both accessibility and performance by playing with Lighthouse for my own personal webpage! The circles to get to 100 "gamified" getting a perfect score. I have found that improving one score often helps the other! From there, I: Read each of the errors that came up, and did extensive research on each, how it impacted users. Added axe to my workflow and checked its error messages, reading Deque's recommendation to fix. Read WCAG specs to understand the theory, supporting with Mozilla Docs . Used PowerMapper to see how things actually operate with real tests. Learned how to use the assistive technology that comes native with my computer and phone! (VoiceOver for iOS/MacOS and my keyboard!) The topics that I started with that I found the most interesting were: Content hierarchy and order: We often think of h-tags as a way to adjust size of text, but it should be considered separately from that. Keyboard accessibility: Is everything that the user needs to interact with accessible from a keyboard? What happens when we engage interactions like carousels and modals? As a power keyboard user, I love when a website is super fast for me to use from my keyboard! Colour contrast: How do I still keep things colourful and elegant while ensuring it's visually perceivable? My core advice would be: Accessibility is a constant evolution. We are never "done" making something accessible. You will find conflicting advice. It's because each tool/framework/library we use introduces another layer of accessibility. It's okay that what you find is competing, try to research extensively and make a decision based on the most knowledge you have. There is not a right or wrong answer, usually. Build in a strategy to perpetually fix things instead of trying to get them perfect at the onset. It's easy to say "well, it's hard to make this accessible at all, so we'll just move accessibility work to the next phase." It's better to do a little (and make mistakes and learn) than to never do it. Ask questions and test with real users! Lastly I offer a free course on YouTube how to get started making your design systems and style guides more accessible.

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!