00:00:06.799
Hello! Just real quick, a little bit about me. I'm a senior software engineer at Red Canary. I have an adorable cat that I did not bring with me, unlike Winter, which would have freaked out.
00:00:11.799
Who here knows what a Renaissance Fair is? Okay, more than I thought!
So, this is mostly an American thing; they're not historically accurate, but they're like giant nerd fests in the summer. Everyone wears costumes, and I'm that kind of person who wears costumes.
00:00:21.560
Here's what we're going to talk about today. A note: I mentioned in the description for this talk that I would touch on APIs and specs. Unfortunately, for time, I had to cut those sections, but come talk to me if you're interested, and I'd love to chat about it.
00:00:39.120
So first, why is this even a talk? When we think about accessibility, typically we're considering the front end, the user interface. So why, as people who work on the back end, do we even need to think about this at all? There are also internal users, which is kind of the big focus of this talk, especially since we're not addressing APIs.
00:01:05.600
A couple of statistics: 16% of people globally have some kind of disability; 20% of people have dyslexia; and 8% of men are color blind. Seeing a lot of men here today, I would be very surprised if none of you were color blind. And it's not just older people. I think sometimes we have this stereotype that, as people get older, their vision starts to go or their mobility starts to get worse. However, one in 12 adults under 35 have a disability. This really does impact a wide range of people. This means that there may be at least one of your coworkers who has one of these conditions, and they would benefit in ways big and small from our products and our processes being more accessible.
00:01:57.600
The best part is these kinds of improvements benefit everyone. So let's take a look at a few examples. Who here uses an Alexa or something similar? Okay, I think the laughter means a lot of people. I don't actually, but the first full text-to-speech synthesizer was invented in 1976 to help the blind community.
00:02:13.200
How many people listen to audiobooks? Yeah, a lot of people raised their hands. The first audiobook was recorded in 1932 by the American Foundation for the Blind. How many people use an electric toothbrush? Yeah. I found that fascinating! These were invented in 1954 for people with mobility issues. All of these inventions or designs were originally intended for specific populations that had some kind of disability, and now everyone uses them.
00:02:51.920
So the point here is, even if something may have a neutral impact on you—like maybe you don't use an Alexa, but you use a regular toothbrush—adhering to these accessibility standards and thinking about what’s going to make people’s lives easier across a wide spectrum is really important. It often leads to unexpected benefits for everyone else.
00:03:16.799
So what do we mean by accessibility? Many of us probably think of color contrast or navigating by keyboard, but it really goes far beyond that.
00:03:21.159
This is from the U.S. Centers for Disease Control. They define disability as any condition of the body or mind that makes it more difficult for the person with the condition to do certain activities and interact with the world around them. This is a fairly broad definition.
00:03:45.760
What kinds of states or experiences might fall under this broader definition of disability? Long-term disabilities are those we often think of, such as blindness, ADHD, and paralysis. However, there are many temporary disabilities as well that could more likely impact yourself or your co-workers.
00:04:05.399
For example, if you broke your arm, had long COVID, or experienced whiplash. Someone here was on a train for a long time, and their neck really hurt. That could impede your ability to do your job in some ways.
00:04:32.020
There are also experiences or conditions that can make your job more difficult. For example, do you have any coworkers who speak a different first language than the rest of the team? Our early-career programmers might have babies at home, not getting enough sleep, which can affect their ability to concentrate. Some may be using a different tech stack in their current role than they did at previous jobs.
00:05:03.679
These are all conditions of the mind or the body that make it more difficult to carry out certain activities. We want everyone on our team to feel supported, included, and empowered to do their best. A lot of that comes down to minimizing struggle wherever possible.
00:05:39.300
If we make our products accessible but not the processes by which they are built, our development practices themselves can be inaccessible. This is from a talk by a software engineer at AWS who, due to a hereditary condition, started to lose vision over time.
00:06:00.000
There are two main ways we can approach accessibility from the back end: the code itself and general practices. Let's first take a look at the code. If there's one thing you take away from this talk, avoid abbreviations and acronyms. Thank you!
00:06:17.760
It's so easy to do, and I catch myself doing it all the time. But when we avoid using shorthand, we decrease the need for context or interpretation, which helps to prevent confusion and misunderstanding.
00:06:32.560
Let me give you an example I actually heard at my current job: 'Can you bug TSSE to connect with the CSM about AWS and CB?' Now I know what that means, but when I first started, I had no clue. The more time it takes to evaluate each of those acronyms or abbreviations, the less you're able to focus on the rest of the content, and you start to fall behind. So, let’s just not do it. First, when we talk about code, we consider readability, naming, and linters.
00:07:05.440
How do we approach readability in a way that makes our code more accessible? We all know that naming is one of the hardest things. A big focus is how we find a balance between meaning and length. The more verbose we are, the more characters we use, generally the easier it is to understand.
00:07:27.120
However, the shorter it is, the easier it is to skim. When we think about line length, there are also issues for people with certain concentration issues who may find it difficult to get across and absorb the content in one go.
00:07:52.520
Pronounceable words are important as well. If you're pairing with someone and you're reading code that has variable names with no vowels, how do you pronounce that out loud? So, how do we make our code readable? This also makes it better for screen readers because they literally read the code out loud.
00:08:12.400
Let’s look at some examples. It's a little small, but what we care about is what we’re naming our variables. In the first example, we just have variables like 'failed' and 'old', saying 'If failed or old, do something.' But what does 'fail' mean? How do we know it’s too old? There's just not enough context.
00:08:39.280
In the second example, we provide more context: we have 'has reached max fails before continuing.' Instead of 'old,' we have 'has been running longer than acceptable.' It’s very obvious what’s going on, but that’s a lot of characters.
00:09:17.560
This middle ground gives us a balance with: 'reached max fails' and instead of 'old,' we have 'running too long.' This gives us enough context without needing to literally spell everything out.
00:09:40.200
Let’s look at another example. I emphasize that code should be unambiguous and self-documenting. Using meaningful placeholder names in loops is essential. Who here has occasionally done something like using 'x' as a placeholder? Yeah, I see some hands. I know it’s faster to type but it’s much harder to read.
00:10:04.560
I once looked at a spec file that was 600 or 700 lines long. The top let statement was 'let s equal subdomain.' I was interested in one test around line 450 that simply called this 's.' I had no idea what 's' was, so I had to scroll back up to figure it out, which wasted time.
00:10:30.640
Changing 's' to 'subdomain' in a pull request made it so much easier to read. Again, like we've talked about, we want our code to be pronounceable. Here’s an example of making it clearer: instead of 'CB equals message.Gsub new line character blank string,' we can say 'carbon black equals message.delete new line.' These have similar functions but reading the first one requires more mental parsing.
00:10:50.840
Linters are incredible for accessibility for several reasons. They help maintain consistency in your code, making it predictable. If someone comes to your codebase for the first time, being able to look up the list of rules your company follows and enact those saves time and clarifies everything.
00:11:15.280
At Red Canary, we use a variety of linters to maintain accessibility. Now, some general best practices: when we think about accessibility in our code, line lengths are important. The default for RuboCop is 100 characters because we read best between about 75 to 100 characters.
00:11:38.600
For instance, if you look at the New York Times website, which is text meant for online reading, their line length doesn’t go above 79 characters. Keeping those shorter lines not only benefits screen readers but also helps people with dyslexia.
00:12:05.240
Making it so that we're not stretching all the way across the screen or having to scroll in your editor ensures that you can see everything at a glance. This makes it easier to skim and find parts of content you’re interested in.
00:12:37.320
There's a balance between following recommendations that might not work for people and what truly helps. You might be thinking, 'Why are we talking about screen readers? How many programmers are actually blind?' Remember that blindness is a spectrum.
00:13:02.680
Some people might only see the outside, while others have a total loss. According to Stack Overflow's 2023 developer survey, almost one in 50 developers are blind or have vision issues. Additionally, many people lose vision over time, which highlights the importance of making our code accessible.
00:13:41.000
I have a coworker who I know to magnify my screen when we share it to make it easier for him to engage with the content. Here's another example: even if both of these pieces of code are formatted the same, one format reduces whitespace, making elements closer together.
00:14:03.520
While that may not fit everyone's aesthetic preference, accessibility is a broader concern. The analogy is if you have an uncomfortable chair in the office. It may look cool, but it is essential to create a comfortable environment for everyone.
00:14:29.400
Moving on to documentation, which is a huge part of our jobs. One of the things I emphasize is to keep your documentation updated. I have a repeating monthly calendar event where I review documentation I’ve contributed to and ensure it’s current.
00:15:03.200
Traditional accessibility practices related to documentation include avoiding images of code. It is often frustrating when you’re following a guide and it’s an image of a script rather than text.
00:15:39.040
If you have to use an image for something, consider including the actual text below. Use semantic HTML: start from H1s and work your way down. Make the lists easy to read, so it is less overwhelming with big blocks of text.
00:16:14.160
For example, if you have documentation that features a video, include captions and transcripts. This is something we have started focusing on at Red Canary. One of my colleagues and I discovered that we could have a Zoom session while playing a video, which would generate an accurate transcript.
00:16:46.080
Additionally, we realized that keeping documentation simple can assist those with concentration issues. Approximately one in ten programmers have a concentration or memory disorder consistently.
00:17:16.920
The same factors may disturb others temporarily too. Thus, avoiding complete blocks of text can help everyone. Simple writing can benefit a wide range of users.
00:17:54.440
This may seem like a small detail but avoiding ampersands can benefit screen readers. Keeping sentences short—15 to 20 words—yields better comprehension. Readability can decrease dramatically with longer sentences.
00:18:29.640
A good tool for testing readability is Hemingway for English texts. There are also other tools available for more languages. Link text should be informative rather than vague so users know where they are heading when they click.
00:19:06.080
Using dates and times in unambiguous ways is vital to avoid confusion. Avoid using socially charged terms in tech language. Instead of 'white list,' try 'allow list.' When writing, be mindful of cultural context and avoid assumptions that may inadvertently exclude people.
00:19:47.880
Conversely, adding your pronouns to your profile can make an impact. Avoid saying things like it should be easy. Instead, express that you expect it to be straightforward but allow space for difficulty.
00:20:23.600
Let's quickly discuss engineering policies that improve accessibility. This includes policies such as flexible work schedules, choosing vendors that prioritize accessibility, and offering a diverse range of tools.
00:20:51.040
This ensures programmers with disabilities can thrive. Additionally, if we ensure our front end is accessible, that significantly improves usability for back-end engineers.
00:21:14.800
Key takeaways: most of the work for accessibility comes from small individual efforts. Making small changes can benefit everybody. Even if you rarely touch the UI or interact with users, you can positively impact accessibility in your workplace.
00:22:03.320
And finally, please avoid using abbreviations! Thank you!