Learning to Listen for What Doesn't Belong: A Blind Student's Path Into Cybersecurity

There is a particular sound a terminal makes when it is working for you. It is not really a sound, of course. It is my screen reader reading back what I typed, then reading what the computer said in return. A command goes out. A few lines come back. The voice reads them at a speed that would sound like static to most people, and somewhere in that stream is the thing I was looking for: an open port, a failed login, a file that should not be there.

When I first spent real time in a command line, I remember thinking it was the most honest interface I had ever used. There were no icons pretending to be buttons. No menus that only opened when a mouse hovered over them. No pictures of text. Just text, going in and coming out, in order. For someone who has used computers by ear his whole life, that felt less like a new skill and more like coming home.

I am blind. I have been since birth, from a condition called Leber congenital amaurosis. I am also a musician and producer who records as Mr. Blindbandit, and right now I am a student in a two-year cybersecurity associate program at Virginia Western Community College in Roanoke. When I tell people that, I can usually hear them trying to picture it. How does a blind person do security? Isn't it all dashboards, graphs, blinking alerts on a wall of monitors?

Some of it is. A lot of it is not. And the gap between what people imagine and what the work actually involves is exactly why I think more blind students should be looking at this field, and why the field should be looking harder at us. This is what I have learned so far about breaking into cybersecurity without sight: why I chose it, what is genuinely hard, what is easier than people expect, and what I would tell another blind student who is thinking about it.

Why a musician ended up studying security

People sometimes treat my interest in cybersecurity as a swerve away from music. To me it is the same instinct pointed in a different direction.

I have spent years building things online by myself. Music releases, a record label, a website with a lot of moving parts. When you build your own presence on the internet, you find out fast that anything connected to the internet is being poked at constantly. Passwords matter. Accounts get targeted. Settings you did not understand turn out to be important. I wanted to understand what was actually happening underneath the things I had built, instead of hoping they were safe.

There is also something about the way security people think that feels familiar. In music production, I work without seeing waveforms. I listen for problems. A click, a hum, a frequency that is fighting with another one. I have trained myself to notice small things that do not belong. A lot of defensive security is the same habit. You learn what normal sounds like so that you can hear the thing that is off.

And, honestly, there is the practical side. I wrote in an essay on this site, The Best Post-Secondary Path Is the One That Fits the Student, that education should be chosen for a reason, based on a student's goals, accessibility needs and finances. A community college associate program in cybersecurity fit that for me. It is focused. It is concrete. It builds toward skills and credentials employers actually recognize. Before this I finished high school through Penn Foster with a 4.0 GPA, which I wrote about in Penn Foster Gave Me a Way to Graduate. Finishing that chapter gave me the confidence to take on something harder.

What the work actually is

When people picture cybersecurity, they picture a movie: someone typing furiously while a progress bar fills up. The real thing is quieter and far more text-heavy than most people realize.

A lot of it is reading. Logs. Configuration files. Documentation. Security advisories. Policies. A lot of it is understanding how systems talk to each other: networks, protocols, operating systems, permissions. A lot of it is written communication, explaining a risk clearly to someone who is not technical. None of that depends on sight. All of it depends on patience and on being comfortable absorbing large amounts of information in a structured way.

That last part is something blind people practice every day whether we want to or not. When you use a screen reader, you take in the world one line at a time, and you learn to build a picture in your head of how the pieces connect. You learn to navigate by structure. You learn to search instead of scan. Those are not bad habits for someone whose job may involve reading through thousands of lines of logs looking for one that does not fit.

Linux is a good example. Much of the security world runs on Linux, and much of Linux can be run entirely from a text terminal. Command-line tools print text, and text is what screen readers are best at. Tools like Nmap, which maps what is running on a network, can be driven completely from the keyboard. Even for tools that are known for their graphical interfaces, there are often command-line versions. Wireshark, the well-known packet analyzer, has a terminal counterpart called tshark. That pattern shows up again and again. The graphical tool may be hard. The text version underneath it is often usable.

I do not want to oversell this. Not everything in the field is accessible, and I will get to the parts that are not. But the core of the work is closer to reading and reasoning than to looking at pictures, and that surprises a lot of people.

Where it gets hard

Here is the honest part.

The hardest thing so far has not been the concepts. It has been the containers the concepts come in.

Training platforms, virtual labs, and course software were mostly not designed with screen readers in mind. A common setup in security education is a virtual machine you reach through a web browser. You click a button and a remote desktop opens inside the page. To a sighted student, it looks like a computer inside the browser. To my screen reader, it is often a picture. The remote desktop is streamed as an image, and there is nothing in it the screen reader can read. The voice goes quiet. The lab is right there, and I cannot get into it.

The same thing happens with some simulation tools, especially ones built around dragging and dropping devices onto a diagram. Network diagrams in general are a challenge. A picture of a network is a very efficient way for a sighted person to understand a topology, and a very inefficient thing to describe line by line. I have learned to ask for the same information in a different form: a table, a list of connections, a written description of which device talks to which.

Then there are the platforms themselves. Learning management systems, quiz tools, video lectures without captions or transcripts, PDFs that are really just scanned images of pages, practice questions that show a screenshot and ask what is wrong with it. Each one is a small barrier. Stacked together, they turn a class that should take a certain amount of effort into one that takes more.

None of this is unique to security. It is the same set of problems I describe in What the Internet Sounds Like When You Can't See It. It is just that in a technical program, the stakes are higher, because the inaccessible thing is often the exact thing you are being graded on.

Certifications and the question of the test

If you look at entry-level cybersecurity jobs, you will run into certifications quickly. CompTIA's A+, Network+ and Security+ come up constantly as common starting points. They are often part of the path through programs like mine, and many employers use them as a first filter.

For a blind student, the obvious question is: can I take the test?

What I have learned is that the answer usually depends less on the content and more on the testing setup, and that it pays to ask early. Major certification bodies have processes for requesting testing accommodations. The details vary by vendor and by testing provider, and they change over time, so I am not going to tell you exactly what will be approved. What I will say is this: find the official accommodations page for the exam you want, read it carefully, and start the request long before you plan to test. Accommodation requests can take time, and some require documentation. You do not want to find that out the week before your exam.

It is also worth asking specific questions. Will the exam delivery software work with the screen reader I use? Are there questions that depend on interpreting an image, and how will those be handled? Is extra time available? Can I take the exam in a testing center, online, or both? The more precise you are, the better the answer you will get.

And prepare in the format you will actually be tested in, if you can. Practice questions are only useful if you can read them. If a practice platform is inaccessible, say so, and look for alternatives. Books in accessible digital formats, text-based study guides, and your own notes in plain text can carry you a long way.

The tools I lean on

I am not going to pretend there is one perfect setup. There is not. But I can tell you what helps me.

A screen reader I know deeply. It does not matter much which one. On Windows, NVDA is free and JAWS is a long-standing commercial option. On a Mac, VoiceOver is built in. On Linux, Orca is the common graphical screen reader, and there are other options for pure terminal use. What matters is knowing your screen reader's commands well enough that it disappears. Every minute I spend learning keyboard shortcuts pays itself back many times over.

A comfortable terminal. I spend a lot of time in a text environment because it is predictable. I learn tools that can output plain text, and I learn to filter that output so I am not listening to a thousand lines when I only need ten. Knowing how to search, sort and narrow down text is a security skill in its own right, and it happens to be the skill that makes a screen reader efficient.

Plain-text notes. I keep notes in simple text files so I can search them and so nothing is locked inside a format my screen reader struggles with. I recommend the same habit to musicians on the site in the guide on screen readers and music work, and it turns out to work just as well for commands, lab steps and study material.

AI, used carefully. AI assistants can help explain a concept in a different way, describe an image in course material, or help me organize my own study notes. I use them. But in a field where accuracy matters, I treat what an AI says as a starting point, never as the final word. If it tells me a command does something, I check the documentation. Security is not a place to trust a confident guess.

Asking for access without apologizing for it

One of the most important skills I am building has nothing to do with computers. It is learning to ask for what I need clearly, early and without apologizing.

When a lab is inaccessible, I do not just say "I can't do this." I try to say exactly what is blocked, what I am using, and what would help. The remote desktop is not readable by my screen reader. Is there a command-line version of this lab? Can I get the diagram as a written list of connections? Can I get the lecture transcript? Specific requests get specific answers. Vague ones get sympathy and very little else.

Most schools have a disability or accessibility services office, and it is worth connecting with them before a class starts, not after you are already behind. Instructors, in my experience, often want to help but have simply never been asked this particular question before. Sometimes you are the first blind student they have had in that course. That can feel like a burden. It can also be a chance to make the path easier for whoever comes after you.

That idea matters to me a lot. It is part of why I am building the Mr. Blindbandit Access and Opportunity Foundation, which is still in formation. One of the things it is meant to focus on is exactly this: assistive technology, digital skills and technology education, so that the next blind student who wants to study something like cybersecurity spends less energy fighting the container and more energy learning the content.

Why the field needs blind people in it

I do not want to be anyone's inspirational story. I want to be good at the job. But I do think blind people bring something useful to this field, beyond the fact that we deserve access to it like anyone else.

We are, many of us, expert troubleshooters. Using technology through a screen reader means constantly working around things that were not built for you. You learn to try one approach, then another, then another. You learn that the obvious route is not the only route. That is a big part of how security testing works.

We also tend to notice when something is built carelessly, because careless design is usually the first thing to break for us. An unlabeled control, an error message that is not announced, a form that behaves differently from the keyboard than from a mouse. Those are accessibility bugs. Sometimes they are also clues about how carefully the rest of the system was built.

And there is a simpler point. Security teams protect systems that everyone uses, including disabled people. Having people on those teams who use technology differently makes it more likely that security measures will be designed so they protect people without locking them out. Think of every login screen that relies on a visual puzzle, every verification step that only works if you can see a code in an image. Someone should be in the room asking whether a blind user can get through it. I would like that someone to sometimes be me.

What I would tell another blind student

If you are blind and curious about cybersecurity, here is what I would say, as someone still in the middle of it and not someone who has everything figured out.

Get very good at your screen reader first. It is the foundation for everything else.

Get comfortable with the command line early. Learn basic Linux. Learn how to navigate directories, read files, search text and chain commands together. It will make you faster and it will open up tools that graphical interfaces hide.

Look at the program before you commit. Ask admissions or the department what software and lab platforms they use, and whether a blind student has taken the program before. Ask for a demo of the learning platform if you can. Accessibility should be part of how you choose a school, not something you discover in week three.

Connect with disability services before classes start. Bring specifics.

Plan certification exams well ahead, including accommodation requests.

Expect some barriers, and do not take them personally. They are usually the result of nobody having thought about it, not of anybody deciding you do not belong.

And keep going. The work itself is more accessible than the path to it. Once you are through the gate, a lot of what you find on the other side is text, logic and patience. Those are things many of us have been practicing our whole lives.

Listening for what does not belong

I come back often to that feeling of the terminal talking back to me. A command goes out. The answer comes back. The voice reads it quickly and evenly. Most of the time, it is exactly what I expected. Every so often, there is a line that is different. A service I did not know was running. A permission that is wider than it should be. A login from somewhere it should not be.

That moment, hearing the one line that does not belong, is the same moment I chase in the studio when I am listening for the click that should not be in a mix. It is the same instinct I use crossing an unfamiliar room with a cane. You learn what normal sounds like. You pay attention. You catch the thing that is off.

I did not choose cybersecurity in spite of being blind. In a lot of ways, I chose it because of how being blind taught me to listen.

Follow Mr. Blindbandit

If you are a blind student, an instructor, or someone working in security who wants to talk about making this field more accessible, I would like to hear from you:

• LinkedIn
• Reddit
• YouTube
• Instagram
• TikTok
• Facebook
• Spotify
• Apple Music

More official links and business contact information are on the Connect page.