How to Accessibility if You’re Mostly Back-End

Talks

Hilary Stohs-Krause

#developer-experience-dx

#ruby-on-rails

#inclusivity

How to Accessibility if You’re Mostly Back-End

by Hilary Stohs-Krause

The video features Hilary Stohs-Krause at RailsConf 2024 discussing how back-end developers can contribute to accessibility within tech environments. The session aims to broaden the understanding of accessibility and its importance beyond just front-end development, emphasizing that inclusivity should be an overarching goal for all developers. Key points covered in the talk include:

Definition of Accessibility: Accessibility refers not only to external users but also internal colleagues who may face various challenges, emphasizing the broader need for inclusivity.
Statistics on Disabilities: Presenting statistics showing that a significant portion of the population has disabilities—including 16% globally—and many of these conditions can affect younger individuals as well.
Impact of Accessibility Improvements: Historical examples such as the invention of text-to-speech and electric toothbrushes underline how accessibility features often benefit everyone, not just those with disabilities.
Readability in Code: Hilary stresses the need for code clarity by avoiding abbreviations and acronyms, enhancing readability, and making documentation more understandable for all developers, including those who may use screen readers.
Use of Linters: Linters are highlighted as valuable tools for maintaining coding standards and consistency, making code more accessible and easier to follow.
General Tips for Improvement: Recommendations include keeping lines of code shorter for easier comprehension, proper indentation, and using descriptive method names.
Catering to Diverse Needs: The session acknowledges that disabilities can be invisible and that accommodating various working styles and preferences—especially in remote settings—is critical.
Fostering a Supportive Culture: Encouraging open discussions about accessibility challenges creates a more inclusive environment. The speaker concludes with a call for actionable steps toward improving accessibility at work, focusing on kindness and communication.

Hilary wraps up the talk by inviting attendees to reach out for further discussion on the topic and by offering fun swag as an engagement tool. The overarching message is the necessity for back-end developers to engage with accessibility to improve inclusivity across the board!

This session serves as a reminder that accessibility is not merely the responsibility of front-end developers, but a collective responsibility that ultimately benefits everyone in the tech community.

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!

RailsConf 2024