Being a blind engineer at tb.lx
My name is Rui Batista and I’ve been working as a backend engineer for tb.lx for the last three years. And I’m blind. In this article I’ll try to share a bit about my experience, the tools I use to do my job and, how tb.lx adapted to integrate me. The article is written in the first person and very much from a personal point of view.
Beforehand, I kindly ask you, the reader, to drop some expectations though: visually impaired people are not and must not be confined to charity or some specific jobs and roles, neither are they superheroes or highly smart people. Don’t judge the ability of a blind person (or any disabled person) to live their life as if you were to become disabled tomorrow and had to go to work the same way as before. That’s not how it works.
The article is structured as follows: I’ll start by explaining my hiring process, what was similar to everyone else’s (spoiler alert, almost everything) and, from that, explain the specific accessibility tools I use to do my job and the adaptations and changes the company made to create the most inclusive work environment possible. I’ll conclude with some final remarks.
##The hiring process
Let’s start from the beginning: the hiring process. Some engineers working at tb.lx knew me from the Scala programming language community and conferences. tb.lx sponsored a conference where I was a speaker and had lots of fun, I had some discussions on Twitter with other engineers and I came up on the tb.lx recruiting radar. What happened next was fairly usual; phone interview, technical challenge, technical interview and cultural fit interview. The disability and accessibility topics were obviously a subject of conversation during this process but, and this is very important, they were not the focus of our conversations. The focus was, as it should have been, how season 8 of Game of Thrones didn’t fulfill our expectations… I’m kidding. Just plain old software engineering skill evaluation, soft skills, and cultural fit. It seems that I did well on those.
##Bring on the Stupid Questions
Then, it came the different stage of this process: what we fondly call the “Stupid questions conversation”.
None of those questions were stupid neither uncomfortable. Actually, these are the questions that should be asked when hiring a disabled person, instead of assuming whatever, and concluding they won’t be a fit or could be too much of an inconvenience. And what questions were those then? Basically, something like: “What are the different tools you use to do your job, if any?”, “How does that screen reader thing work, really”? “What can we, as a company, do or change to create the best working environment possible for you”? “Ah, when can the office manager pet your guide dog?”. So, let’s use the rest of the article to answer some of these, because they cover much of what was and still is my experience at tb.lx.
Let’s start with the technical madness.
###The Screen Readers and Accessibility Chat
Me, and most visually impaired people use software called screen readers to interact with a computer, smartphone, and other devices. Let’s side-step a bit to explain what these are. These software do mainly what the name implies, which is to read out loud what is present on the screen, using speech synthesis. They do a bit more though: they change some of the interactions with user interfaces to make them accessible using virtually only the keyboard; they provide ways to navigate with the information on the screen and quickly access important information depending on the context; they provide Braille output and input to complement or replace speech output; and they have a bunch of other features.
Screen readers are fairly well-known technologies being present for a long time in virtually all relevant operating systems: Windows, Mac and Linux. Most of them are actually free, and even Open Source, with some commercially available exceptions.
The only thing screen readers require to work properly is that applications, websites, and user interfaces in general are designed keeping accessibility in mind and following existing standards and libraries. That’s not rocket science, namely when accessibility is considered in the design phase. Still, it requires some attention, awareness, and know-how.
Many applications are accessible these days, including development tools and well-known productivity suites like Office. Most web-based platforms can also be made accessible with little effort and good development practices, many of them are accessible without the developers even thinking about it. With the right choices there are no extra costs for an employer to hire a blind engineer or for most other roles, and they can use mostly the same tools as everyone. And if it happens that extra accommodations are necessary, governments have programs to cope with these possible extra costs, plus some financial incentives.
On the other hand, an application is not necessarily either fully accessible or completely inaccessible, the same way it’s not bug-free or complete garbage. So, I won’t say that life is a breeze for blind computer users but it’s not hell on earth either. Proficiency with Screen Readers is truly required for any visually impaired person to have a successful career these days, namely in the IT industry. It’s just one more buggy piece of software we need to cope with daily.
###Engineering tools and accessibility
Given visually impaired people use Screen Readers and these require accessible applications to work properly, the tools and platforms a company uses internally and externally can make the difference between an accessible and inclusive environment and a painful working experience for both parts, the company and the employee.
Choices in this field are even more relevant for software development: a big deal of our working day is interacting with each other in collaborative platforms like chat applications (MS Teams, Zoom), development portals like Github or Cloud provider management consoles, monitoring applications, etc. If these are not accessible, it’s hard or impossible for a blind developer to be productive and contribute on the same terms as other team members. The truth is that most of these platforms are not fully accessible, and some are really not at all. However, the majority of these, being web-based, are fairly usable without screen readers, some practice and experience and some magical incantations at solstice. And this is my experience in tb.lx with Github, Azure and others.
Another very important point of contention for software development is the choice of IDE — Integrated Development Environment. In companies where that is prescribed or heavily restricted, one might end up in a situation where the only permitted choices are not accessible or usable with screen readers and other assistive tools.
Giving the developer the choice of tooling is, in my opinion, beneficial to everyone and, many times, essential for a blind developer like me.
My personal setup might be a bit unusual these days, but not unheard of; I’m an [Emacs] user and convert, sometimes using [VisualStudio Code] on some tasks. Why? Because I’m more productive and part of the alternatives are not accessible for real usage (IntelliJ, I’m looking at you.).
## Communication and Other Adaptations
Software development is not just about the tech and geeky stuff, though. “Communication is Key”, so let’s have a conversation on that.
By the way, screen readers are very talkative and fast speaking. When you work with a blind person, you’ll occasionally hear strange things speaking.
The characteristic that actually differentiates a blind person from others is that they don’t see, or don’t see enough (you thought I’d be giving you news…) to use their vision for most everyday tasks.
Given that humans use vision to perceive 85% of all information they acquire, this fact might impose some minor… inconveniences :).
The main limitation in relation to other people has to do with communication. And there is lots of non-verbal communication, mainly visual. Blind people can’t perceive and interpret these communication cues; either pictures, diagrams, gestures… at least in the same way. Note, however, that there are other kinds of non-verbal communication: tone of voice, agitation, etc. Things that visually impaired people can perceive and, in many cases, are even more attentive to.
It’s then important to me as a blind person that the people that interact with me find complementary ways of communicating when the main expected mean of information transmission is using visual cues. Let’s use Software development as an example: there are some obviously apparent problems in this field: how to communicate essentials such as UML diagrams, sequence diagrams, ugly things people draw on boards or, most critical, those funny memes?
And the answer might surprise you: I actually don’t care about your fancy diagrams and boards, only for the concrete concepts that are depicted there. Diagrams are just a convenient representation of some abstract concept that can be communicated verbally, sometimes in an easier manner. Just talk. And to be honest, everyone is supposed to talk with each other when creating these artifacts. And who does UML anymore, really?! Ah, and this actually works also very well when you can’t share your Screen or board on Teams.
###Communicating with a blind person
What I’m trying to show here is that communicating with a blind person is not unnatural or different from what people do daily in their very own lives: everyone needs to explain something on the phone now and then, and everyone describes things to others when telling a story. Yes, maybe you won’t make a drawing when a blind person is not being smart but… That’s not the end of the world.
What we’ve been doing at tb.lx is basically this: talking. Having conversations. Describing things to me, or me asking people to describe things. When working with good people in a good team, that was never an issue, always an advantage. Everyone needs help in one way or another.
Generalizing these ideas to a company’s environment, it is important to account for the somehow specific communication needs of visually impaired employees in company activities and processes.
Some clear points to have in mind:
- Describe images that are relevant to understand some content;
- Don’t send text embedded in images for purely aesthetic reasons (or due to laziness);
- Verbally explain the visual content of a presentation;
- Try to use accessible formats and consider accessibility in procurement processes for working tools and platforms, etc, etc, etc.;
- And be open to failures and a never-ending story;
- Ah, and don’t forget team buildings and off-work activities: Inclusion must be taken into account in these situations, and they are actually a very good opportunity to raise awareness on these sorts of topics, in a funny and enjoyable way.
At tb.lx I was always involved in these processes, and still am. Everyone from Engineering to HR made an effort to make the company a better place for me which made the company better for all, I’m sure.
## Final Remarks
tb.lx is not the only company integrating blind people as myself, neither the only place where I felt included and valued as any other engineer. However, my path in tb.lx is representative of a very important takeaway when dealing with disability and diversity matters: It’s not for companies or for society to define or restrict what is possible for disabled people to do professionally.
The place for companies is to ask what is possible and give opportunities accordingly, to improve with these insights and get the results back. Some impossibilities might come along, the results of overcoming them might surprise you but surely they won’t disappoint, as they didn’t for tb.lx and for myself.
This article was written by Rui Batista, Backend Engineer at tb.lx and based in Lisbon, Portugal. 🚛🌿
