How to Accessibility if You’re Mostly Back-End

Ruby

Hilary Stohs-Krause

#developer-experience-dx

#team-building

#diversity-inclusion

How to Accessibility if You’re Mostly Back-End

by Hilary Stohs-Krause

The video "How to Accessibility if You’re Mostly Back-End" by Hilary Stohs-Krause explores the often-overlooked role of back-end developers in promoting accessibility within technology. The discussion emphasizes that accessibility is not just a front-end concern, and that back-end practices significantly influence the overall user experience, particularly for internal users.

Key points discussed include:

- Understanding Accessibility: The speaker clarifies that accessibility extends beyond visual elements and includes holistic experiences affecting various disabilities, including temporary conditions. Statistics on disability impact highlight the importance of being mindful of accessibility in technology development.

- Code and Documentation Practices:

- The speaker urges back-end developers to avoid abbreviations and acronyms to enhance code readability and user comprehension.

- Complex coding examples illustrate how providing meaningful variable names leads to clearer code, aiding other developers and tools such as screen readers.

- Emphasis is placed on documentation maintenance, ensuring clear instructions that are accessible to a diverse audience, including the use of simple language and avoiding images of code unless necessary.

- Designing for Inclusivity:

- The benefits of accessible design are underscored, with historical examples showing that tools initially created for individuals with disabilities have generalized advantages, thereby benefiting every user.

- Workplace Policies: The discussion includes recommended engineering policies, such as flexible schedules and using accessible vendors, to create an inclusive work environment for all developers, including those with disabilities.

In conclusion, Stohs-Krause encourages back-end developers to take an active role in enhancing accessibility through small, individual efforts, as even minimal changes can positively impact their workplace. By emphasizing communication, documentation practices, and mindful coding, back-end developers contribute to a more accessible environment for everyone. The session reinforces that accessibility is a shared responsibility across the tech stack, urging developers not to dismiss their influence in this critical area.

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!

See Slides on helvetic-ruby.ch

Helvetic Ruby 2024