The Web and Media Accessibility Group AMA 🎉

Held on 8 May 2020, 5:00 pm

Hello everyone 👋,

We will be having a group AMA with:

  • Jen Luker (Senior Frontend Engineer)
  • Obinna Ekwuno (Software Engineer & DevRel at Gatsbyjs)
  • Segun Ola (Medical Doctor & Software Engineer at Andela)
  • Tatiana Mac (Independent American deseloper (designer, then developer))

They will be answering your #a11y questions live from May 8th, 05:00 PM GMT onwards.

Topics we'll cover include but not limited to:

  • Web Accessibility
  • Media Accessibility
  • Other similar topics.

Shoot us your questions in the comments below! 👇

EJ Mason's photo

What are your favorite stories about accessibility victories you were involved in? Did those victories teach you anything that might help the rest of us achieve more victories?

Show +1 replies
Tatiana Mac's photo

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.

Segun Ola's photo

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.

Bolaji Ayodeji's photo

Hi Jen, Obinna, Segun and Tatiana ;) Thanks for this AMA.

IMO, I think accessibility is hard because most of its concepts are not included in the basics. Most of us had to learn how to make our applications accessible after building them for a very long time hence most developers see it as stress. Why do you think accessibility is not included in fundamental courses just like you're taught "forms" in every HTML course?.

Do you think this is changing and how can we embrace this?

Show +1 replies
Segun Ola's photo

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.

Tatiana Mac's photo

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.

Paula Borowska's photo

Also, thank you all :)

Matt Kreiling's photo

Are there ever occasions when a non-interactive element should be in the tab order?

In testing output from a popular eLearning software, I found that the method for providing text (rendered as images) was to add aria-labels and then make different parts of the markup focusable and tabbable so screen-reader users could tab to the content to hear it read.

Also, I cannot find anywhere in WCAG which says that non-interactive elements should not be in tab order.

Show +2 replies
Matt Kreiling's photo

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

Tatiana Mac's photo

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.

Bolaji Ayodeji's photo

Accessibility has become widely know and sort-for topic with a lot of developers and organizations advocating for the need to focus more on it towards building for the Next Billion Users. Lately, I've been trying to learn more about auditing accessibility and testing accessibility on the web.

What do you think about testing the accessibility of your project until it complies with all the accessibility standards and guidelines?

Show +4 replies
Tatiana Mac's photo

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.

Segun Ola's photo

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.
Heidi O's photo

A lot of the conversation about web accessibility focuses on development, but how can other disciplines contribute to make the sites we build more accessible?

Tatiana Mac's photo

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!

Jen Luker's photo

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.

Diana Hudson's photo

I think I understand what web accessibility means, but I'm not sure how we can make media files accessible. Can you share some more insights, please?

Show +2 replies
Obinna Ekwuno's photo

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 . Please check it out. It offers some insight on how you can understand and implement Media Accessibility

Tatiana Mac's photo

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


  • 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="")


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

Paula Borowska's photo

Although accessibility is widely accepted and highly important in the design department at my company, we do have issues getting content writers and especially developers interested and accountable in accessibility. I work at a large org. What have you found that works to get other teams invested in accessibility?

Segun Ola's photo

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.

Tatiana Mac's photo

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.

Marcus Hicks's photo

How can I get started with improving the accessibility of my previous and future projects? Can you recommend any resource, please?

Show +2 replies
Segun Ola's photo

Just like you test for performance and correctness in your products, you should test for accessibility. There are several tools for automated testing like linter plugins, CI tools and browser dev tools. These provide you with a baseline. Watch this chat on accessibility testing. We also mentioned a few things we like to test for. The holy grail for accessibility testing still remains manually testing.

Also, as Obinna Ekwuno already mentioned there are tools and guidelines for building accessible products and UI elements.

Adewale Olaoye's photo

Segun Ola The chat is awesome. Thanks for sharing

Diana Hudson's photo

Does accessibility only apply to web development? How can I apply it to android development?

Show +1 replies
Segun Ola's photo

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:

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

Tatiana Mac's photo

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?
Adewale Olaoye's photo

This is Nice, for the first time I follow Accessibility talk and I understand what it is. Currently, checking what I'm working on Accessibility. Thanks, everyone

Adewale Olaoye's photo

I am using Lighthouse to view the results on different websites I've worked on, I noticed Performance is poor, Accessibility and SEO is good.

I guess React Eslint helped with flagging errors which helped boost Accessibility and SEO, How do I improve Performance?

Les Stuck's photo

After I try to make an accessible web design, how do I find people to test it?

Chong Yi Hoo's photo

hope to see more this kind of talk

Chong Yi Hoo's photo

good stories

Paula Borowska's photo

What advice do you have to help get buy-in for accessibility from stakeholders, decision makers or even PMs?

Show +1 replies
Jen Luker's photo

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.

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?"

Tatiana Mac's photo

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.