00:00:10.360
Hello and welcome! You are all here today for the session on how to approach accessibility if you're mostly back-end.
00:00:15.759
Our speaker today is Hilary Stohs-Krause. Hilary is a senior software engineer at Red Canary and serves as a board member for several tech and community organizations. She loves board games and bourbon barrel-aged stouts, and she got way too into plants during the pandemic. So, without further ado, please welcome Hilary!
00:00:43.120
Alright, so we're going to talk about how to approach accessibility when you're primarily working on the back end of the tech stack. This is mainly about how we create inclusive tech environments, not only for our users but also for our colleagues. That's a key focus of today's discussion.
00:01:01.160
A little bit about me: as mentioned, I'm a senior software engineer at Red Canary. I have an adorable Ragdoll cat, the same breed as Taylor Swift’s cat, if that means anything to you. I'm also the kind of nerd who dresses up when I go to the Renaissance Fair.
00:01:21.119
Today, we will begin with a brief introduction explaining what we mean by the term 'accessibility.' This is one of those words that can mean a lot of different things. Afterwards, we'll get specific about how to address accessibility in our code and explore some of our general practices.
00:01:40.200
First, why do we even need to worry about accessibility? Typically, we think about external users when we hear the term, and we tend to focus on the interface and the front end. However, we also must consider internal users. Here are a couple of stats: 16% of people globally have some kind of disability. 20% of individuals have dyslexia, and 8% of men are colorblind.
00:02:00.799
It's also important to note that accessibility concerns are not limited to older people. In fact, one in 12 adults under 35 has a disability. This means that there's a strong chance that this includes one or more of your coworkers. Imagine how they would benefit—both in significant and minor ways—from our products and processes being more accessible.
00:02:25.599
The best part is, we often hear that accessibility improvements benefit everyone. For example, Alexa—who here has an Alexa or a similar device? [Some audience members raise hands] Great! The first full text-to-speech synthesizer was invented in 1976 specifically to help the blind community, and now these devices are in many homes.
00:02:56.159
Audiobooks have a similar story; the first one was recorded by the American Foundation for the Blind in 1932. Similarly, who here uses an electric toothbrush? [Audience responds] Wonderful to hear that everyone is practicing good dental hygiene! Those were invented in 1954 for individuals with limited motor skills.
00:03:15.200
These tools initially served specific communities that needed that extra boost, but it turns out we could all use that boost. Even if you don't think accessibility improvements would help you personally, such practices matter, especially as consumers increasingly care about accessibility—legally as well as commercially.
00:03:46.159
So, what do we mean by accessibility? We've heard some stats regarding how many people have disabilities, but it goes much deeper than that. According to the US Centers for Disease Control, the definition of disability is: a condition of the body or mind that makes it more difficult for the individual to perform certain activities and interact with the world around them. This definition is quite broad.
00:04:19.400
What are some states that might necessitate accessibility? We often think about long-term disabilities, such as blindness, ADHD, paralysis, and so forth. However, we must also consider temporary disabilities. For instance, you might break your arm, experience long COVID symptoms, or suffer whiplash from a car accident.
00:04:54.639
Moreover, we need to acknowledge those conditions or experiences that can make everyday tasks more difficult: co-workers with a first language different from the rest of the team, or those who are early in their careers. Other factors to consider could include having a baby at home—which leads to less sleep and increased stress—or adapting to a different tech stack than what they previously worked with.
00:05:21.280
We want everyone on our team to feel supported and included, minimizing any struggles they might face wherever possible. While we make our products accessible, we must also ensure that our development practices are also accessible.
00:05:41.840
Now, as an engineer at Red Canary who has experienced vision loss over time, I've witnessed firsthand how critical it is to approach accessibility from two main perspectives: the code itself and our general practices. If there’s one thing I want you to take away from this talk, it is this: avoid abbreviations and acronyms. I’m going to repeat that several times throughout the presentation.
00:06:11.240
Why? Because abbreviations increase the need for context or interpretation, and by avoiding them, we can decrease confusion and misunderstanding. Many abbreviations can refer to multiple different concepts. For example, I heard this phrase at Red Canary: "Can you bug TSC to connect with the CSM about AWS and CB?" After nine months there, I understood it, but when I first started, I was scrambling to understand what all of those abbreviations meant while trying to listen to the rest of the conversation.
00:06:49.960
This brings us to the importance of code readability. We all know that naming is one of the hardest aspects of writing software. The challenge lies in finding a balance between meaning and length. Let me show you a few examples. We want to convey our intention without resorting to excessively long variable names.
00:07:17.960
The more verbose a name is, the easier it is to understand, but too short makes it harder to comprehend. We need to use pronounceable words. If one of your variables can't be easily pronounced or lacks vowels, it becomes challenging for screen readers and for developers trying to read your code.
00:08:02.680
Let's take a look at some variable names. In one scenario, we named two primary variables 'failed' and 'old'. While these tell us something, they don't convey a lot of meaning. In another example, we have 'has_reached_max_failure_before_finishing' instead of 'failed', and 'has_been_running_longer_than_acceptable' instead of 'old'.
00:08:38.160
While those names are incredibly descriptive, they're far too lengthy and that creates a problem in terms of readability. A better example combines clarity and conciseness: 'reached_max_fails' and 'running_too_long' – these provide the key information but don't overwhelm with unnecessary detail.
00:08:58.720
The goal is to make your code unambiguous and as self-documenting as possible. We also need to use meaningful placeholders in loops instead of letters that have no context—this is a personal pet peeve of mine.
00:09:21.920
A common example from my experience at Red Canary involves using 'S' as shorthand for 'subdomain,' referring to our client accounts. It was confusing to navigate large spec files filled with instances of 'S.' I had to trace back through the code to understand its meaning. It could easily have been written as 'subdomain'. This in itself is far clearer.
00:09:46.839
Similarly, choosing method names that read like sentences can improve clarity, especially in a language like Ruby, which is meant to be more grammatically aligned to English. For instance, instead of 'CB equals message.gsub(new_line_character, blank_string)', we should write something more akin to 'carbon_black equals message.delete(new_line_character)'.
00:10:02.960
You can see they accomplish the same task, but one is more intuitive to read and comprehend. Linters are also incredibly useful in enhancing readability for accessibility.
00:10:20.280
How many of you use linters at work? [Audience responses] Many of you! This is great. Linters help maintain consistency in coding, which is essential for accessibility for several reasons. Consistent rules are easier to follow, creating a predictable experience for developers.
00:10:57.760
If you're unsure how to structure a piece of code or you're adding something new, you can just look it up, rather than guessing. At Red Canary, we love our linters. We use Ruby Cop, ESLint, and HAML Lint for documentation files. Linters are fantastic.
00:11:20.519
Now let's discuss some general tips for improving readability in code. Line length is one of the principal aspects when it comes to readability. Specifically, Ruby Cop's default line length is set to 100 characters for a reason. Research shows we read most comprehensively between 75 and 100 characters.
00:11:37.600
Take a look at the New York Times website—an outlet designed for reading vast chunks of content. Their average line length is around 79 characters. Additionally, writing shorter lines of code is often better for screen readers.
00:12:08.720
Shorter lines are also beneficial for readers who are dyslexic or having a hard time concentrating. When someone is tired or stressed, having clean documentation and shorter lines helps comprehension.
00:12:32.720
Indentation is another crucial aspect to consider. This is about finding the balance between what your linter enforces and what is genuinely readable for humans.
00:12:53.160
When discussing screen readers, it’s vital to remember that, according to Stack Overflow's 2023 survey, nearly 1 in 50 developers are blind or have vision issues. Blindness is a spectrum. So, it’s essential to create environments that are accessible in varying degrees of visual ability. For example, we might overlook how many developers are visually impaired when designing our interface.
00:13:30.799
One of my coworkers wears magnified glasses to view their screen, which impacts how they work. By making small changes in how we format our code, we create a far more accessible environment for everyone.
00:14:06.320
Another important aspect is recognizing that we often work from home. This brings in individuality, as many of us might have different work habits or preferences, making it crucial to continue promoting accessibility in our products and practices.
00:14:27.839
One of my colleagues began using hearing aids, which I didn't even know until we met in person. It really emphasizes the point that many disabilities are invisible and that we should not assume everyone is perfectly healthy.
00:14:52.200
Moving on, it's worth mentioning that abbreviations and acronyms should be avoided as much as possible. This is one of the key points of our discussion today. Clarity is paramount in documentation, so it's best to write things out.
00:15:09.760
This is part of the core values we uphold in our workplace: authenticity and kindness. Striving for accessible environments is not just right, but it also supports productivity and efficiency. As accessibility in the workplace improves, everyone benefits.
00:15:23.480
Let me encourage everyone here today to take away some actionable suggestions. Focus on improving readability, avoiding the use of confusing abbreviations, and always remember to communicate with kindness. If we foster an environment where individuals feel comfortable discussing their challenges with accessibility—no matter how small—that's a victory for all.
00:15:49.600
I would like to wrap up with my contact information. If anyone has further questions about this topic, feel free to reach out to me. Also, if you enjoy fun swag, I have some socks to give away!
00:16:01.920
Thank you for your time, and I hope you found this session valuable!