Search posts, tags, users, and pages
Hello everyone 👋,
We will be having a group AMA with:
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:
Shoot us your questions in the comments below! 👇
After I try to make an accessible web design, how do I find people to test it?
What advice do you have to help get buy-in for accessibility from stakeholders, decision makers or even PMs?
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.
If your website is accessible, you could be cornering the market for those with disabilities!
Being accessible opens your business up to government entities
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…
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.
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?
Different approaches for different folks.
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.
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.
h tags work, could you label your copy doc?For developers, I've found tapping into their desire for consistency and reuse:
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.
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?
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.
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.
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?
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:
Product managers and owners place a huge role in ensuring accessibility is considered at all phases of the project by all project contributors:
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:
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.
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.
⚠️ 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
General advice
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> elements.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.
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?
Does accessibility only apply to web development? How can I apply it to android development?
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
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?
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
<text> for any embedded textalt="")Video
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.
Hopefully that gives you a start to do more research! 🤓
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?
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.
Tatiana Mac
Open Source Maintainer/Developer
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.
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?
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.
Adewale Olaoye
FrontEnd Developer
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