In this video we’re exploring what it means to have an invisible disability and how that can and should impact the way you build and design products. We wanted to thank Invisibledisabilities.org for putting together the A11yChicago meetup that inspired our exploration of the subject with UX Developer Christina Deemer. You can watch the original meetup here. Also, during the video you’ll notice mention of guidelines and industry standards. You can find those web content guidelines here. We highly recommend everyone checks them out. Below the video you’ll find a transcript you can follow along with and captions have been provided by YouTube’s automated system. Since this is new for us, be sure to let us know if you’d like to see more videos like this in the future!
Christina Deemer — User Experience Developer
My name is Christina Deemer. My pronouns are she/her and I’m a UX developer at Alley. My work focuses on front end, structure, layout styling, and user interaction. I work mostly in REACT, and I have a special interest in accessibility. I’m really grateful that I had the opportunity to attend the panel discussion at the Chicago digital accessibility and inclusive design meetup. This meetup was one of the highlights of my time in quarantine at home since the pandemic began. I’m really grateful to the speakers, to Fen Slattery, Keidra Chaney, and Santina Croniser for being so vulnerable and authentic and discussing their experiences as technologists and as people who live with invisible disabilities.
What Inspired you?
These days a lot of real-life meetups have gone virtual, and a silver lining to that is that we can attend meetups that we otherwise wouldn’t have been able to attend. I’m not going to go to Chicago because I’m in the Philadelphia area, and a colleague of mine who is an accessibility specialist pointed out this talk by the Chicago digital accessibility and inclusive design Meetup.
It seemed really cool and had a really great lineup of speakers. I had seen Fen Slattery speak at Liberty JS last fall and their talk was one of the highlights of the conference for me.
The other two panelists were Keidra Chaney and Santina Croniser. Fen and Santina are engineers, and Keidra is a digital strategist, and the panel discussion was on invisible disabilities.
All three panelists have invisible disabilities.
What is an invisible disability?
Invisible disabilities are physical, mental, or neurological impairments that are not visible from the outside but can limit a person’s mobility, senses, or activities. Invisible disabilities can lead to a lot of misunderstandings, false perceptions, and judgments.
Examples of invisible disabilities include mental illnesses such as bipolar disorder and schizophrenia. Chronic health conditions like lupus and MS. Neurological conditions like ADHD and autism. They can also include hearing and vision impairments, and what I learned is that all disabilities are invisible on the web.
You don’t know if the person who uses a screen reader has been totally blind since birth or is losing their sight to a degenerative condition and is just learning to use a screen reader at age 35.
Every panelist actually mentioned that they regularly use screen readers or voiceover technology though none of them are blind. They use it because it helps them focus on large bits of text because listening to content can be less taxing during times when they’re experiencing a lot of pain or sensory stimulation.
You just don’t know who the end-user is. You don’t know if the person who wants to navigate your site with a keyboard has a severe permanent mobility issue or if they have dyspraxia and find keyboard navigation to be more reliable than using a mouse.
What makes something inaccessible?
The web can be a very physically uncomfortable and emotionally unwelcoming place for people with disabilities.
Autoplay videos, ads that flash, confusing forms, crowded sidebars, pages without hierarchical headings, sites that can’t be navigated with the keyboard, not knowing what’s going to happen when you click on a link: if it means it’s going to take you to another page or if you’re going to have to download a PDF.
For some people, having really annoying flashes on a webpage is just annoying or a nuisance. For people with invisible disabilities like autism, ADHD, or epilepsy, those flashing ads or animations can be disorienting or distracting at best. At worst, they can cause meltdowns, seizures, migraines, or other painful issues. So while the web can help bring people together and provide access to things they might not otherwise have had access to. There can be many barriers for a lot of people
Why might someone prefer assistive technologies?
A lot of times, when we talk about screen reader users, we assume that the opposite of a screen reader user is a sighted user. But there are many users who are sighted who also use screen readers or voice-over technology. Because the visuals can be overwhelming, taxing to read, or there is a certain font that’s used that’s hard for somebody with dyslexia to read. It just might be more comfortable for them to use voiceover or screen readers.
How do you make a site that accommodates all digital literacies?
You won’t ever know who your end-user will be, and someone’s comfort level may change depending on context. So while you may feel very comfortable with your particular laptop and your home office space and you’re comfortable navigating through a complex form – let’s say you’re going to buy a pair of jeans so you’re comfortable figuring out the right size that you need getting it into your shopping cart and adding your payment information.
Your comfort level with that may change if you’re trying to execute the same task in a crowded subway on your phone and Maybe you don’t have a really great connection – and it’s like that for everybody, we sort of go through various modalities throughout our day, throughout our life. What made you feel comfortable, what you were comfortable with today may not be your situation tomorrow.
A few years ago, I broke my elbow and was in a cast for a little while that went from my wrist to my shoulder, and I was navigating my keyboard with one hand so doing things that were comfortable the day before I broke my arm were not as comfortable the very next day. That was a temporary situation for me, but it’s just an example of how our situations change over time and even just throughout the day. So how do we address that in design, or content, or when we’re building? That is to prioritize that the needs of the people who are most vulnerable or the people that are going to have the most difficult time because when you build for those folks you are going to make a higher quality experience for everybody. This is why, you know, captions on videos – the people who use captions on videos are not only people who are permanently a hundred percent deaf or have a hundred percent hearing loss.
All sorts of different people use captions, and it’s the same sort of thing. A little tooltip that tells you how exactly to enter your username or your phone number in a form.
That tooltip or that little bit of note of direction not only helps people who have neurological or cognitive differences that may make that hard to understand it helps a lot of us when we don’t know how they want us to enter our phone number, you know, in a form so I think prioritizing the most vulnerable, prioritizing the people who have the most difficulty — is the way to go.
How do you get started?
I think it’s important to educate yourself about the web accessibility standards. That’s always the sort of first way to go. Whether you’re a content creator, a designer, or a developer, there is some part of web content accessibility guidelines that apply to you, and there are sites that will filter the rules by role.
So if you’re a content creator and you only want to see the rules that are relevant to your role, you can do that. I think taking a little bit of time to learn about those and then well that is a great first step and then actually I think that anytime you can do any sort of user testing, or talk to users, or you know go to meetups to learn about accessibility. That will help go a long way.
The rules can be very dry — and it can seem, like, well, why is it important that that sites have a certain color contrast? Why does that matter? Sometimes having a name or a face to put with an accessibility need can help make it feel real. You shouldn’t need to have to meet somebody and talk to somebody who uses a screen reader or who uses high contrast settings when they’re ordering groceries online like – for it to seem important because you should just want to do this. Because it’s the right thing to do. Sometimes I’m reminded of people who say, “Well, I care about women’s issues now that I have daughters” and it’s like you shouldn’t need to have that personal connection, but sometimes it can help. So educate yourself about the standards, then go to meetups or talk to people, do user testing, and then sometimes it’s about using those accessibility tools yourself.
How do you address mistakes respectfully?
Sometimes accessibility issues fall through the cracks. They just do. So as a developer, or a designer, or a content creator – if you notice something, if you see something, say something. Wherever you are in the project, of course we want to identify accessibility needs early on in the project because as you get further down in the project, remediation can become more expensive. So we want to take care of all of this stuff early on because it is cheaper and more efficient. Let’s say you know 75% of the way through the project, you, as a developer, notice that some aspect of the site isn’t navigable by keyboard. Make a ticket for it! Tell the client, just say “you know we want to note this is an issue and that we’re going to take care of it” or “we have it in the back log, we’re going to take care of it” or if for some reason your videos don’t have captions and you want to post the video right away, it needs to happen, so maybe you can tell your users “we don’t have captions, we’re sorry, we know this is important, we value all of our users, we’re going to get them up in a week, or they’ll be up tomorrow” but I think at least acknowledging the the gaps helps it sort of validate that these things are important. That we do see these things as important but, as a developer, I know that that’s something that I’ve done — I notice an accessibility issue, I make a ticket for it.
When do you incorporate this into a project?
I think the ways that it can be effective when reviewing designs for accessibility and, as soon as possible, addressing issues around color contrast and tab sizes. That sort of thing can be tremendously helpful. If you can adjust a shade of gray so that it meets accessibility standards, if you can address that issue in design, that takes care of a lot of things. You know, that’s a lot easier than having to negotiate that later on in the process. Similarly, with making buttons, you need them to be a little bit larger, or tab sizes need to be a little bit larger. It’s a lot easier to address those in the design stage and to have conversations about accessibility in discovery. It is tremendously helpful so that everybody understands where the gaps are, what the sort of pitfalls can be; identifying those before something’s actually built can be easy.
There are some things like keyboard navigation that you can’t address with design, but again like building for those people in need and being aware of them as people and making it part of the AC for a ticket so that a ticket doesn’t pass until the work is accessible. It helps going ticket by ticket rather than, “oh hey, we’re 75% of the way through, and I noticed that this is the defect across the site” like that’s a lot heavier lift then this ticket for navigation isn’t going to pass until the menu is completely keyboard accessible.
Why is accessibility important to you?
So a lot of times, people, if they are in a position where they can’t use an app that maybe they have to use for work or they can’t use it without getting additional accommodations — having to disclose their invisible disability to their employer can be a risk.
So if when you’re building, designing, or creating content for something: if you can make it so that somebody can just be themselves and not need any additional accommodations, that everything just sort of works for them — you’re helping that person out a lot.
It really shouldn’t be, and this is sort of a big thing for me. It shouldn’t be left to the people with disabilities to do all of the advocacy for themselves. People without disabilities should be advocates for people with disabilities. When I think about the Domino’s Pizza lawsuit because their app wasn’t accessible to visually impaired folks. How many meetings were there? How many testing sessions were there? Where somebody or many people could have spoken up or could have said, “this is not okay. This has to be accessible” and how many people didn’t? And it was left to the person with the disability to take on the burden of making the complaint. When all they wanted was a pizza, you know, people should just be able to have the pizza! They should just be able to — you know — access the new site. They should just be able to fill out the form because somebody without a disability advocated for them in discovery, in design, when creating content, and when building their site.
What can we do right now?
So if people are interested in some next steps to take and how to learn more about this, I recommend really diving into those two web content accessibility guidelines. Learn more about how specific guidelines are important for your role. I think having more of a general understanding of those guidelines can go a long way. If you’re particularly interested in learning about invisible disabilities, you can visit the Invisible Disabilities Association at invisibledisabilities.org