Latest / The Diversity Career Podcast with Fexingo: Inclusion, Equity, and Underrepresented Professionals / How One Company Made Blindness a Career Strength
Transcript
- Lucas: Luna, I want to talk about a program that a major Silicon Valley tech company ran a couple of years ago. They set out to hire blind and low-vision software testers and data labelers—not as a charity initiative, but because they found that blind testers were actually better at catching certain kinds of bugs than sighted testers. Luna: Wait—better how? I'm imagining a screen reader reading code or UI elements, but I wouldn't think blindness would give you an edge in visual software. Lucas: That's exactly the counterintuitive part. The program focused on visual UI bugs—misaligned buttons, broken layouts, color contrast issues that a sighted tester might subconsciously overlook because their brain fills in the expected visual. A blind tester using a screen reader hears the raw structure: tab order, heading hierarchy, alt text. If something's missing or out of order, it's glaringly obvious. Luna: So the screen reader essentially exposes the skeleton of the interface, and if the skeleton is broken, they catch it immediately. Lucas: Exactly. The company's internal data showed that teams including blind testers had a 30% lower post-release defect rate for UI issues compared to teams with only sighted testers. And the blind testers themselves reported promotion rates faster than the company average for equivalent roles. Luna: That's a striking outcome. But I want to push back a little—does this say something about inclusion, or does it say something about clever task segmentation? They're essentially carving out a niche where a specific disability becomes an advantage. Lucas: That's a fair challenge. And the company was pretty upfront that this was a pilot—they weren't claiming to solve all of disability employment. They identified a role where a particular access need—screen reader compatibility—wasn't just accommodated, it was the primary mode of interaction. And they redesigned the job around that. Luna: So instead of saying 'we need to make our testing process work for blind employees,' they said 'let's make blind employees the core of our testing process.' Lucas: Right. And that flipped the traditional accommodation model. Usually, you hire someone sighted, and then you bolt on accessibility tools. Here, they hired people who already used screen readers as their primary interface, and then optimized the workflow around that. For example, they invested in Braille displays for rapid scanning of code blocks, and they trained sighted managers on how to interpret screen reader output. Luna: What about the data labeling side? That seems even more surprising—labeling images, videos, that feels inherently visual. Lucas: It is, but they found a workaround. For certain labeling tasks—like identifying objects in audio or labeling text in scanned documents—blind labelers were actually faster because they weren't distracted by the visual noise. One labeler told the company that when she couldn't see the background clutter, she focused purely on the audio cue or the text string. Luna: So that's a specific cognitive advantage. But I wonder about the career ceiling. Were these dead-end roles, or did people move up? Lucas: The data showed movement. Within two years, about 40% of the initial cohort had moved into senior testing roles, or into accessibility engineering, or into product management. The company deliberately created a pathway: after six months, testers could apply to an internal accessibility rotation. Several became trainers for the next cohort. Luna: That's a real career ladder, not just a token placement. I'd love to know what the retention numbers looked like. Lucas: Retention at the two-year mark was 85%, compared to 70% for sighted testers in similar roles. The company attributed that to the sense of purpose and the fact that the work was genuinely using their skills—they weren't just sitting in a corner doing busywork. Luna: It also suggests something about how we think about 'disability.' The typical framing is that disability means you can't do something. But here, the disability itself was part of the capability. Lucas: That's the deeper point. The company effectively treated blindness as a design constraint that led to better outcomes for everyone. The screen reader-friendly workflows they built also made the testing process more efficient for sighted testers who preferred keyboard navigation. And the bug reports from blind testers were often more precise because they couldn't rely on vague visual descriptions—they had to be specific about element IDs and coordinates. Luna: So the entire QA process got better. That's the kind of 'universal design' argument that often stays theoretical. Lucas: Exactly. And I think this is replicable beyond testing. You could imagine similar approaches in accessibility auditing, transcription, data annotation for audio, even customer support roles where screen reader proficiency is a plus. The key is to stop asking 'how do we accommodate this person?' and start asking 'how would we design this job if the primary user were blind?' Luna: That's a much more ambitious question. It's not about fitting people into existing boxes—it's about rethinking the box. Lucas: Right. And it aligns with a broader shift I'm seeing in disability employment. More companies are piloting what they call 'disability-first' job design. They start with a specific access need and build the role around it, rather than hiring someone and then retrofitting. Luna: What's the risk? I can imagine critics saying this is just a new form of segregation—putting disabled workers into special silos. Lucas: That's a real concern. The company was careful to frame it as a starting point, not an endpoint. The goal was to create a bridge into the broader organization. And the fact that people moved into mainstream roles suggests it worked as a bridge, not a silo. But if a company just parked people there indefinitely, that would be a problem. Luna: So the success depends on whether there's a genuine path upward. Lucas: Exactly. And transparency about that path. The company published internal career maps showing exactly what skills testers would gain and what roles they could move into. That kind of clarity is rare in any hiring program. Luna: Speaking of clarity—if this episode was worth a coffee to you, we'd love it if you'd support the show. It helps us keep the podcast ad-free and accessible to everyone. You can do that at buy me a coffee dot com slash fexingo. Lucas: We really appreciate that. And it's a small way to tell us that these kinds of deep-dive conversations matter to you. So thank you. Luna: Alright, back to the topic. One thing I'm curious about: what did the sighted testers think of working alongside blind colleagues? Lucas: The company did anonymous surveys. The majority said they learned new debugging techniques from their blind teammates—like relying more on keyboard shortcuts and screen reader output for spot-checking. Some even started using screen readers themselves during certain phases of testing. Luna: So the inclusion program became a skills development program for everyone. Lucas: Exactly. And that's the kind of multiplier effect that justifies the investment. The pilot cost about two million dollars over two years—including training, assistive tech, and workplace modifications. But the company estimated that the reduction in post-release defects alone saved them about five million in rework and customer support. So it paid for itself. Luna: That's a strong business case. But I wonder how many companies are actually willing to make that upfront investment. Most DEI budgets are still pretty small. Lucas: They are. But this program was championed by the VP of Engineering, not the DEI team. That made a difference. When a line executive owns the budget, it's treated as an engineering investment, not a social cost. Luna: So the lesson might be: find a business problem that disability inclusion can solve better than the status quo. Don't lead with the moral argument. Lucas: That's exactly what happened here. The company had a quality problem: too many UI bugs slipping through. They tried more sighted testers, automation, nothing worked. Then someone in accessibility suggested: what if we hire people who can't see the interface, so they have to rely on structure? Luna: And that reframed the conversation entirely. It went from 'we should do something for blind people' to 'we have a problem that blind people can help us solve.' Lucas: Right. And once the results came in, there was no going back. The program expanded to a second site last year. They're now testing a similar model for accessibility auditing of mobile apps. Luna: That's a great sign. It suggests the initial success wasn't a one-off. I'd love to see more companies adopt this kind of approach—not just for blindness, but for other disabilities too. Lucas: Absolutely. Imagine a similar program for deaf data analysts who excel at visual pattern recognition, or for autistic testers who thrive on repetitive precision tasks. There's so much potential if we start from ability rather than deficit. Luna: That's a powerful way to end. Thanks, Lucas. Lucas: Thanks, Luna. Until next time.