How to Accessibility if You’re Mostly Back-End, by Hilary Stohs-Krause
Abstract
If you work mostly on the back-end of the tech stack, it’s easy to assume that your role is disengaged from accessibility concerns. After all, that’s the front-end’s job! However, there are multiple, specific ways back-end devs can impact accessibility - not just for users, but also for colleagues.
Description
When we think about “accessibility”, most of us associate it with design, HTML, CSS - in other words, the front-end. If you work primarily on the back-end of the tech stack, it’s easy to assume that your role is disengaged from accessibility concerns.
In fact, there are multiple ways back-end devs can impact accessibility, both for external users and for colleagues.
In this talk, we’ll walk through everything from APIs to specs to Ruby code to documentation, using examples throughout, to demonstrate how even those of us who rarely touch HTML can positively impact accessibility for all.
Notes
Key Takeaways:
Clear, specific ways to immediately start improving accessibility in your work and in your Ruby code.
Accessibility isn’t just about folks with obvious disabilities; it can affect wide groups of people in disparate ways.
Many accessibility practices are individual and low-effort.
Making our content and code easier to access benefits everyone (including both external users and colleagues).
Pitch:
When we talk about accessibility, we often think about meeting WCAG requirements for our website or application’s customer-facing user interface. Rarely do we think about accessibility in our code, our specs, our documentation - but all these places have an impact, and everyone has a role to play in improving them.
I’ve worked on accessibility for a variety of projects over the years, primarily on the front-end - but after working with colleagues who faced additional challenges as developers (English wasn’t their first language, or they were autistic, or they were a new parent), my idea of what it meant to create “accessible” projects expanded. Now, when I think about accessibility as a full-stack developer, I’m think about all areas of the tech stack, as well as my larger team culture and our work processes.
Making it easier to work with our code and our products benefits us, our colleagues, and our users - and who doesn’t want that? ❤️
I break this talk into two main sections: accessibility in the code (readability, API development, linters and specs) and accessibility re: general practices (documentation, communication and flexibility). I include specific examples throughout, and focus on actionable steps that anyone can start to implement, no matter their skill or experience level.