🎯 Conclusion, bibliography and useful resources
In this module
This module concludes the training by giving its key takeaways and linking them together, as well as recapitulating our bibliography, including resources that infused our work even if they were not explicitly cited.
⛳️ Section: E. To conclude and go further
👥 Audience: Everyone
⏱️ ️Duration: 10'
📚 Prerequisites: None
When to use?
This module should be used as a synthesis of the main points of this training as well as a comprehensive list of resources for you to go further than what we covered here.
What to take away from this training?
This section is a reorganized synthesis of the whole training.
What is accessibility?
Accessibility is about designing and building for people who experience disabilities. - From a product standpoint, it's about ensuring everything you build can be used by anyone, no matter their physical or cognitive abilities. - From a legal standpoint, it is an obligation in many countries, guaranteeing an equal right to autonomy and participation of all. - From a software standpoint, digital accessibility comes down to making apps optimally perceivable, operable and understandable to people who live with disabilities. - From a political standpoint, accessibility is striving fight back against the structural tendency to exclusion of disabled people and attempting to provide them with a place (virtual or not) where they feel at ease and free to express themselves.
When products are not built with accessibility in mind, they end up excluding many people, denying them access to places, tools or even communication. This unfair exclusion is called ableism.
Accessibility calls for inclusiveness
Inclusiveness is a core concept when talking about diversity. It's often a preferred term to accessibility, that is rather limited to the inclusion of people with disabilities. It highlights that we need to be designing and programming not only for people who experience disabilities, but also for the ever-varying pluralities of human experiences and discriminations emerging from them. In simpler words, focusing only on accessibility will result in the exclusion of the vas majority of users enduring oppressions.
Here is a non-exhaustive list of human characteristics to keep in mind in order to try and include as many user as possible:
- Age
- Culture
- Digital literacy
- Education
- Ethnicity
- Gender, gender identity
- Historical context
- Language
- Mental health
- Nationality
- Physical and cognitive (dis)abilities
- Sexuality
- Socio-economic context
Intersectionality is a framework for understanding specific living experiences of people situated at the intersection of discriminations and privileges. It’s very useful, for two main reasons:
-
The proportion of users with disabilities who happen to have more than one is important (17.7% in 2016). Thinking about designing for one disability leaves out a blank spot for users having that disability but also other conditions. For example, deaf users with low vision are often overlooked when thinking about accessibility.
-
It’s a common bias to forget that disabled people are not just disabled, but first and foremost people with their own unique life experiences and specificities. We need to think about women who rely on wheelchairs, LGBTQIA+ people who don't speak the language of they country they live in, blind users who can't afford an iPhone - and those who are all of that at once!
Tip
It's crucial to not think disabled peoples as a minority but rather as the living diversity in which we all evolve.
Accessibility and inclusiveness need to be intentional
Disability shouldn't be thought as an individual characteristic. Environment - and the way it is designed - plays an equal role as the body when it comes to disability. For example, in an environment built to be completely flat and non-obstructed, people who walk are way slower than people using a wheelchair.
Rob Whitaker, Developing Inclusive Mobile Apps
Disability is not a binary state. We all have "abilities and limits to those abilities. Disability happens when we have built something that doesn’t work for someone with particular skills.
Additionally, by default, we naturally tend to design, program and test for people like us or the people we spend time with. Not thinking about accessibility is a privilege because most disabled people don't have the choice to think about it. Not developing with accessibility and inclusiveness in mind will reinforce biases against minorities in software.
Accessibility and inclusiveness are very hard to automate. No amount of checklists and tests in CI can replace feedback and testing from diverse user groups. Instead of listening blindly to automated tools, we encourage developing your empathetic gaze and listening to diverse feedback.
Tip
Accessibility and inclusiveness are a shift in how you perceive and take into account otherness through your building processes, not a task to be done.
Disabled people are the real experts on accessibility
We cannot replace the perspectives of people with disabilities simply by reading about them or running a series of automated tests. We highly encourage recruiting people from diverse backgrounds in your team. The whole project will benefit from varying perspectives and it could help to leverage against systemic exclusion and hiring discriminations which affect minorities.
Ashley Shew, Against Technoableism, Rethinking Who Needs Improvement
Disabled people are “the real experts” (the title of Michelle Sutton’s 2015 edited volume about and authored by autistic people) when it comes to technology and disability. We use technologies. We also reject them, grapple with them, or repurpose them. The views on technology we get from listening to disabled people often look very different from those of people educated in the medical and “helping” professions.
As we need to embrace diversity, it is crucial to fight a natural urge of all software creators: the will to personally find, design, and implement the solution to every problem. There is no one solution, and if there were, you would probably not be the one to find it. Your role as a software builder is to reach out to the real accessibility experts: those who rely on accessibility and experience its flaws every day, i.e. people with disabilities. Therefore, rather than trying to produce a "perfectly accessible" and inclusive product, we would rather suggest to try and make the main features as inclusive as possible and then get feedback from diverse users on what are their main issues with your software are.
This does not mean either that your expertise is useless if you are not experiencing the discriminations for which you are assessing your products. As you know the product you are building and what experience you are aiming for, you - as a product engineer, designer, or even developer - will be necessary to understanding what can be enhanced.
Tip
We encourage following this motto: "nothing about them without them"
There isn't one "accessible and inclusive design"
While implementation plays an important role in the inclusiveness, and especially the accessibility of applications, the designers and product managers hold an important responsibility in the process of building an experience that will resonate and be welcoming to the widest range of users possible.
Product design documents, including specifications, user stories and prototypes act as the team’s compass for delivering products. That is why having inclusiveness in mind from the design is absolutely essential. You don’t ever have to “make this feature accessible” if it is built from the ground up with inclusiveness in mind.
Moreover, human experiences are complex and evolving as they always emerge from intersections of those characteristics. Consequently, building an inclusive app is all about staying up to date and actively open to feedback, knowing that we can never reach perfect inclusiveness while doing our best to get there.
Tip
People are diverse, solutions to their needs too. Experiment, fail, get feedback, improve and nurture empathy!
Accessible code is good code
Bad accessibility can often be a symptom of flawed code. Accessibility and inclusiveness in programming have one key benefit: making you think twice about your code. Stumbling into an accessibility issue might mean that you could be doing something better in a different way.
You code can be good but will likely never be as robust as one iterated upon by a community of developers or a big company. Therefore, before implementing anything, check rigorously that your framework (or a library) doesn’t provide a tool that would meet most of your needs.
Tip
Your code cannot be good without being accessible and if it's not accessible, it's probably hiding something more.
The Quick Inclusiveness check
Before submitting a commit or reviewing it, you can also use a template of a checklist containing the main elements to be sounded and share it with your team. We provide you with our own accessibility checklist template. Feel free to iterate upon it and to contribute with your enhancements on this repository.
Remember: this should not be seen as a way to make your UI accessible, but rather to be sure you commit won't break any existing accessibility that was implemented. For new features, it is essential to design the UI with accessibility in mind from the very start of the process.
You can modify it for your needs by downloading this file and opening it in excalidraw.
Perspectives
This training is already coming to a close. - If you are doing this training collectively, you are not quite yet finished as their is still two modules awaiting you. -
We dearly hope it was somewhat useful to you. We feel that there is a lack of resources that dive deep into technical consideration while reflecting on them through a systemic gaze, and placing empathy as a core element of decision-making. We hope this training helps on your path to inclusiveness. As we said multiple time, we are not experts, only people trying to help. If you have expertise on those topics and feel like helping, please contribute. You can also star the repository. If you have any question, feel free to contact us!
Bibliography & useful resources
Tools
Color Contrast Checker & Accessibility Checker | Figma
Articles, book and masterclasses
Winner, Langdon. Do artifacts have politics?, 1980. Daedalus 109 (1): pp. 121--136.
Apple Human Interface Guidelines: Accessibility
Apple. Principles of Inclusive App Design
Apple. The practice of inclusive design
Apple. The process of inclusive design
The A11Y Project. Software, books, blogs, online tools, etc.
McRuer Robert. Crip Theory : Cultural Signs of Queerness and Disability, 1966
FOSS in the army
U.S. Department of Defense. DoD Open Source Software FAQ
Capt. Noe Lorona. Leveraging Free and Open-Source Software on the battlefield., 2024
FOSS and capitalism
Teemu Mikkonen, Tere Vadén, Niklas Vainio. Open source developers and the ethics of capitalism, 2007
Böhm Mirko, Economics of Open Source 2022
Ross Daniel. The Place of Free and Open Source Software in the Social Apparatus of Accumulation, 2013 Josh Lerner, Parag A. Pathak, Jean Tirole. The Dynamics of Open-Source Contributors
Manuel Hoffmann, Frank Nagle, Yanuo Zhou. The Value of Open Source Software
Inclusion in software
Shew Ashley, Against Technoableism: rethinking who needs improvement. 2023
Nathan L. Ensmenger. The computer boys take over, 2010
Blondy Marie Herminie L’idéologie libertaire des pionniers d’internet : Contradictions d’un humanisme industriel, 2025
Open source desktop app with good accessibility
Tools
Microsoft. Accessibility Insights for Windows
Apple. Accessibility Inspector
Articles and videos
Expand the room. Accessibility Testing Tools Overview
Deque. NVDA Keyboard Shortcuts
Challenge Solutions. Screen Reader Comparison
VLE Guru Introduction to Keyboard Navigation and Accessibility
Expand the room. How to Check Web Accessibility with a Screen Reader and Keyboard
Chrome for Developers. *Screen Reader Basics: NVDA -- A11ycasts #09 *
Andreea-QA. Accessibility Testing on Windows Apps, 2023.
The A11Y Project. Software, books, blogs, online tools, etc.
Documentation
Microsoft. Accessibility overview
Microsoft. Accessibility (Design basics)
Direction Interministérielle du Numérique.Guide du concepteur RGAA 3
Jonathan Giles (Oracle), The JavaFX Accessibility API (slides)
Introduction to tools
Apple. WWDC21 Challenge: VoiceOver Maze
Documentation
Direction Interministérielle du Numérique.Guide du concepteur RGAA 3
Direction Interministérielle du Numérique.Référentiel spécifique aux plateformes mobiles/tactiles
Orange. Accessibility Guidelines
Appt. A guide for making apps accessible
Whitaker, Rob. Developing Inclusive Mobile Apps: Building Accessible Apps for iOS and Android
Articles
Brooke Nelson Alexander. 25 Smartphone Accessibility Settings You Need to Know About
Apple
CVS Health. Accessibility Annotation Kit for iOS
Android
Articles
W3C. How to Meet WCAG (Quick Reference)
inclusive-components.design. Inclusive components project
Cristian Díaz. A Guide To Keyboard Accessibility: HTML And CSS (Part 1)
ExpandTheRoom. How to Check Web Accessibility with a Screen Reader and Keyboard
Heydon Pickering. Building Accessible Menu Systems
inclusive-components.design. Menus & Menu Buttons
Cristian Díaz. A Guide To Keyboard Accessibility: JavaScript (Part 2)
Microsoft. Test accessibility using Lighthouse