This article was originally published in German on GAAD.at as part of a series on how Austrian IT professionals approach accessibility in their practice.
As a UX researcher for assistive tech, one of my biggest professional fears is accidentally creating a disability dongle. I have seen a good amount of them across expos, conferences and fairs, so in this newsletter I set out to answer the question: Where does it go wrong?
If you would like to contribute to the Austrian GAAD initiative through an article, video, infographic, case study, or sponsoring, you can reach them at hello@gaad.at
User research is all about finding the right problem to solve. But in regard to accessibility (and accessibility testing with users), there usually exists this double standard that the problem we are looking for is already defined in advance. Barriers.
What kind of barriers? All of them. All barriers which stop you from using a specific product.
Okay, so far so good, but if we think about it: After removing access barrieres, we have only reached the state of an MVP (minimal viable product). At this point, users can just use the product - as we intended it. That’s supposed to be the starting point for usability tests.
When it comes to accessibility, testing is often concluded with: "It works! It's accessible!" Would be cool if it were actually that simple and straightforward!
Through this practice, the product is prioritized over the users. How it should work and especially how it should work best for users with disabilities is often already determined in advance.
'Disability Dongle' describes a product developed for people with disabilities, but does not take their life realities into account. The term was introduced in 2019 by Liz Jackson:
The definition satirizes an outcome in which designs or technologies “for” disabled people garner mainstream attention and accolades despite valid concerns disabled people have about them.
It is a solution to a problem that is not really a problem. A manifestation of "well-intentioned". Examples often include variations of exoskeletons, wheelchairs with stair-climbing function, or AR glasses with automatic subtitles, facial recognition, or recognition of facial expressions.
An example in web design could be overlays1, which are still used even though it has already been scientifically proven that they do not sustainably improve accessibility and user experience2. "Accessible versions" of websites and apps, which are often advertised as "optimized for screen readers”, also fall under this category.
Liz Jackson criticized in particular that people with disabilities are not or only very limitedly integrated into the design process. It is designed for them, not with them.
Another aspect of the issue is that it is often about adapting people with disabilities to societal standards, not the other way around. Instead of addressing barriers that prevent participation in social life, non-disabled product developers zero in on what amounts to more or less cosmetic problems and get hyper-focused on them.
To understand Disability Dongles, it helps to look at the social model of disability:
[In the Social Model] the impairment is not at the center, but the societal conditions and physical barriers that make inclusion difficult or prevent it.3
This thought is often the starting point, the dissonance arises through the different interpretations of "societal conditions and physical barriers." Non-disabled product developers define barriers as something that their perception shows them as external impairments. This leads to misjudgements regarding what disabled demographics want or need, such as the exoskeleton to be able to walk upright, which was mentioned above.
An upright gait is not a determinant for social participation, and a Gundam Mecha suit definitely stands out no less than a wheelchair.
Empathy is the starting point, but it is not a substitute for expertise. Someone who has lived with a disability for a long time (possibly their entire life) will assess what constitutes “a barrier” differently than someone without personal experience. Even with the best intentions, ideas are influenced by bias.
No amount of empathy can replace life experience.
We all carry unconscious prejudices or stereotypical ideas in our heads. In user research, it is important to become aware of them so that we do not let them influence our research. It is never pleasant to admit that you have stereotyped another person in your head. But this confrontation is necessary to leave stigmatization out of the design process.
We are all shaped by our social environment and values. But it is often forgotten that our test users are just as much shaped by them.
Many IT professionals worry about how to speak correctly with people with disabilities and about disabilities. Here we already encounter the first problem:
the "Othering" or making different of people with disabilities. The concept comes from philosophy and describes that we partly define our identity through distinction from others (or other groups). The self defines itself through what we are not:
In philosophy, the Other is a fundamental concept referring to anyone or anything perceived as distinct or different from oneself. This distinction is crucial for understanding how individuals construct their own identities, as the encounter with "otherness" helps define the boundaries of the self.4
This applies to all people and is easily forgotten in user research with individuals from marginalized groups. How people talk about their experiences depends on whom they are speaking with. In a time-limited meeting, we have very limited influence on the psychological safety of the situation. What our participants feel comfortable telling us about their disability (or disabilities) depends heavily on their identification with and confidence in regard to the topic.
Disabilities are not homogeneous. They also do not exist independently of other realities of life, since our life experiences influence each other.
Many disabilities are associated with aging and thus often form an additional dimension of identity: Some people reject the label "disabled" because it is not compatible with their self-perception. This rejection can stem from socialization and the values and stereotypes with which one lived before acquiring a disability. Part of this is internalized ableism:
Ableism refers to the unequal treatment of people based on abilities. Depending on what someone looks like and what gender the person has, where they come from, whether they are poor or wealthy, disabled or non-disabled, someone is considered able or unable (in a certain situation or generally).5
A Disability Dongle is — at its core — a product that cements ableism by demanding that people with disabilities adapt to non-disabled norms instead of designing the environment or circumstances in an accessible and inclusive manner.
Ableism is often invisible because it hides in seemingly “well-intentioned” solutions. If we assume in the design process that we already know what a barrier is, we reproduce exactly this unequal treatment. We prioritize our own perception over the lived reality of our users.
Proper user research can prevent ableism in design. It forces us to question our prejudices, recognize power structures, and practice co-creation instead of mere validation.
For accessibility not to end with an MVP stage, we need to change our approach to accessibility testing & user testing (and stop separating them):
Learn about disabilities: Even within the same diagnosis, disabilities are nuanced. Before talking with test users, study up on about how disabilities actually affect life. You can start on Wikipedia to research common causes and diagnosis, then move on to lived experience reports and educational content by creators with disabilities.
Think about intersectionality: Do not only ask a homogeneous target group, but actively look for different and potentially contradictory voices. Intersectionality is what makes a design robust for various life situations.
Design with, not for: The design process should be led by the opinions and assessments of persons with disabilities. User tests should not only serve as confirmation. The slogan “Nothing about us without us” is heard in every discussion about inclusive design, so why is it still not everyday practice?
Avoid tokenism: One test user is not enough. Look for representative patterns, not confirmation.
Learn from communities: What topics are relevant to the communities? How are they discussed and is there a consensus?
Be critical of your design: Could it contribute to stigmatization instead of reducing it? Would this feature strengthen or restrict the autonomy of users?
Show respect: Learn the basics about disability etiquette. Do not push people to show vulnerability in order to learn from it.
On Global Accessibility Awareness Day and beyond: Inclusion is not a technical feature to be added afterwards. It is an attitude that we must integrate into every step of our design process.

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.