Skip to content

Reframing the Conversation Around Accessibility & Disabilities

When I was 8 years old I played Neopets, the quintessential mid-2000s pet simulator with its own fantasy world, arcade games, holidays, fanfiction, and its own Neopoints-centered economy, complete with a stock market and player-run virtual stores.

As a legally blind kid, most online games weren’t very accessible to me. The colors were always too similar, information was always conveyed in pictures, and there were always funky side-effects whenever I tried resizing text or using my screen reader. Neopets was different. Aside from its (many) Flash games, much of the site’s content — the shops, stock market, trading post, forums, crossword puzzles, world lore, and more — was text-based, or at the very least, written in HTML instead of Flash. Neopets even allowed users to customize their color schemes, backgrounds, and virtual shops, the latter of which allowed users to directly write HTML. I could make my background black, turn my text yellow, bold anything I wanted, and crank up the font size to 24pt. I had finally found something that made my world a little more accessible.

I learned a lot more about accessibility over the following years, both in a colloquial and a “technical” sense, everything from translating pictorial diagrams into text-based ones, to making tactile graphics, to teaching other people how my screen reader worked, to formalizing why I liked that yellow-on-black text so much (color contrast and glare reduction!). I learned how to write a phonetic dictionary for my screen reader so that I didn’t have to keep hearing “juh-query” instead of “jay-query.” I learned how to write aria-labels in HTML, invisible text that only my screen reader would pick up on, and how to pick color schemes that are both pretty for people to look at and easy for me to read.

I also learned that I hated accessibility work. I hated having strangers come up to me in the computer science building and ask if I could accessibility test the app they had built, just because they saw my white cane. I hated having potential employers quiz me on my Java knowledge and run through data structures & algorithms exercises, only to ask if I could do accessibility work after I disclosed I was a screen reader user or needed interview accommodations. I hated going to conferences and getting asked if I was lost or needed directions to the assistive technology session when I was really there for the data privacy talk.

I started doing accessibility workshops not because I loved UX and front-end development, but because I felt like accessibility hadn’t been framed well in the conversations my technical circles were having. Accessibility isn’t about checking the right boxes so that you meet minimum requirements or something that you can think about once your product launches. It’s about caring enough about other people to believe that they deserve the world to be built for them, too. I’m a strong believer in Universal Design and how accessibility usually enhances non-disabled people’s experiences as well (e.g. curb cuts, which are great for wheelchair and cane users, but also strollers, carts, etc.). But even that misses the point a little.

I talk about accessibility to empower other developers. I show them existing accessibility guidelines, incredible communities such as the a11y project, tools that they can use to do their own accessibility testing, and how I use my screen reader and other assistive tech to navigate both my digital and physical worlds. I recognize that I’m in a unique position to talk about accessibility from both a developer and a user perspective and that my experiences can make a compelling argument for why universal design should be a vital aspect to any engineering education. But it’s hard to take the time to explain to an audience how they can learn about accessibility and test their own applications, and still immediately get asked if someone can “pick your brain” for a few hours the next day or test their new website and just “jot down any issues you can find.” It’s hard to defend your identity when people ask if equal access is actually important for their product when “people with disabilities probably won’t be using it anyway.”

I had never met a blind woman working in tech. I didn’t know if people were telling the truth when they told me that “looking at a screen all day might be very hard” for me, or that the sciences were “inherently visual,” or that they weren’t sure I would be able to be an engineer without having to get “too many accommodations.” I didn’t realize how much it would hurt to have someone tell me they “didn’t realize a blind person would be using” their software/their workshop/their space.

Accessibility testing isn’t a full-time job that I want. Accessibility advocacy is something I’m happy to do when the receiving party is happy to listen, but it isn’t just a hobby or a tech talk for me. Accessibility advocacy is something that I need to do in order to cultivate a culture that supports disabled people, including engineers. Including my friends. Including me.

I’m trying to grow into the blind woman engineer that my 12-year-old self so desperately wanted to meet and ask, “Is there space for me here?” Part of that growth is access. Part of that growth is self-determination.

-Lauren Siegel, RTC Fellow + Junior at NC State University

Rewriting the Code- Empowering College Women in Technology

Test Test

Hire more women in tech with Rewriting the Code

Together, we can make the tech industry more diverse and inclusive. Becoming an RTC partner demonstrates your company’s commitment to diversity and inclusion while making a positive difference in the lives of underrepresented communities.

We’d love to connect with your team to learn more about your hiring goals and how to best showcase your company to Rewriting the Code members. Complete the form below to get in touch.

Are you a student? Join Rewriting the Code free here