podcast • 31MIN READ
Beyond Compliance: Fable’s Mission to Improve Digital Accessibility
It's time we recognize that the way we build digital products is broken. That's because the products we use today represent the people who build them more than the people who use them.
There is a digital divide between the experiences of people with disabilities and people who are able-bodied. Bridging this divide is about more than compliance or checking a box.
Fable is helping companies practice accessibility at scale with the goal of operationalizing accessibility in the same way we already do for things like DesignOps and DevOps.
Listen as Fable's CEO and Co-founder, Alwar Pillai, and Fable's Engineering Manager, Perry Trinier, talk about the importance of inclusive design, the need for digital accessibility and how to integrate accessibility into the development process.
Episode Highlights Include:
- Fable's founding story and mission
- The need and importance of inclusive design
- How engineering orgs can improve accessibility
- Making your tech stack more accessible
- Why everyone benefits from inclusive design
Dan Lines: Host
Alwar Pillai: Co-founder and CEO
Perry Trinier: Engineering Manager
Alwar: Each of us, today, use technology that have been designed for assistive technology users first. From, as simple as, an electric toothbrush which was designed for people with motor impairments, but this is something that everyone uses now..
Alwar: You have voice to text [which] was for people with disabilities again and now we have, you know, Siri and Alexa and, like dictation and all of that existed because it was designed for people with disabilities first.
Sponsor: This episode is sponsored by Linear B. Accelerate your development pipeline with data driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo at LinearB.io and mention the dev interrupted podcast discount for one month free when you sign up for an annual pro membership.
[Music fades out]
Dan: Welcome to Dev Interrupted. I’m your host, Dan Lines, and today we are joined by the team at Fable. We have co-founder and CEO Alwar Pillai and engineering manager Perry Trinier. Alwar, Perry, thanks for joining us today!
Alwar: Thanks for having us, we’re super excited to be here.
Dan: Yeah, yeah, awesome to have you here. Now Alwar, let’s start with you and the story of Fable. You founded Fable in 2018 in Toronto. You know you had the goal of making it easy for people living with disabilities to engage in the digital development process. Can you tell us about the path that led you to found fable and what led you to identify the need for Fable.
Alwar: Yeah, for sure. I’m born and brought up in India, I moved to Toronto, Canada in 2015 but I’ve done my bachelor's in user experience design, I got to work in the industry for some time but I was still itching to learn more, so I moved to Toronto to do my Master’s in inclusive design and when I joined this program, it pretty much shifted my entire thinking about how I approach design and how we build products and I recognized just the biases that I had introduced in products that I designed and people that I had left behind. My master’s thesis focuses around how do you design technology for seniors as they age and they start to experience memory loss and can technology play a role in them being more socially connected and that’s what introduced me to the world of digital accessibility and I noticed, like, the digital divide and, you know like, the difference in experience between someone who is able-bodied and their experience online versus someone who lives with a disability and their experience online and it was pretty significant. And while I was doing my master’s and paying for it, which is extremely expensive, I was also funding that by working simultaneously so I had a full time job where I worked with one of Canada’s biggest telco’s as their accessibility manager and I understood the problem from the business perspective of what is challenging for product teams to build an accessible product, what are the tools that they are relying on, what are the processes they’re following and what stood out to me that everyone was just making assumptions on accessibility. No one really understood the needs of people with disabilities. No one interacted with a person with a disability and that’s why the products we use today represent the people who build them more than the people who use them. So I decided to quit my job and star Fable with my cofounder Abid Virani with the goal of, you know, what happens if we connect product teams to people with disabilities throughout the product development process and will that have an impact in the end result of the products that they put out there. That’s primarily the reason why we started Fable.
Dan: That's awesome. So you actually, there was actually a program that you studied in school for this? That’s great.
Alwar: Yeah, it’s called Masters of Inclusive Design and inclusive design is pretty much you can, you can apply it anywhere. The purpose of inclusive design is that the person who experiences the problem should be part of the solution.
Dan: Absolutely. Totally makes sense. Now, Perry, jumping over to you, what brought you over to fable How did you get involved?
Perry: Sure, well, I'm a self-taught web developer, and so my path into web development was never like, What You See Is What You Get kind of editor-web developer, I started using Notepad and eventually moved to better text editors. But I was really into web standards, like, and progressive enhancement, graceful degradation. And so I learned from bloggers like Jonathan Snook, Derek Featherstone and Rachel Andrew. And through that exposure to web standards, I learned a little bit about accessibility and some high-level concepts like making sure that all the functionality would be available from the keyboard. And then later on in my career, I was working at an agency from 2010 to 2016, and I mostly lead projects for financial clients were accessibility was a requirement, so I got to work directly with accessibility consultants, and accessibility vendors to implement accessible patterns. And in that process, learned a little bit more about accessibility and about ARIA. And so my next job after that I was at eBay Classifieds with Kijiji, and there I decided to kind of become an accessibility champion. I did some training. I had awesome mentors from eBay accessibility, and I also had the opportunity to study more and become certified as an accessibility specialist. So then I was looking for a full time position in the field of accessibility. Around that time, a mutual friend of mine and of ours told me that they were looking to hire a lead developer for Fable, and I should start to talk to them. So early on in 2019, I did join fable. I've been really enjoying helping companies to integrate inclusive design into processes.
Dan: Wow, that's great. I did not expect all that background from you in accessibility. That's perfect. I have to say I'm probably novice in that area. So really excited to be learning more as we go through the pod here. But that's really cool Perry that you have all of, that's like, you know, all of our, that's the perfect engineering hire, you couldn't ask for a better (Alwar: Yeah!) candidate to come your way and join the company, right?
Alwar: Totally. Perry was one of our, like, first five employees, and we really wanted him on board. And we made sure we got, like, benefits because Perry was like all of this is needed. So we're gonna get this for the entire team so pumped that he joined us that early.
Dan: Well, that's perfect, because I wanted to dive in a little bit more into your founding story. You mentioned earlier, hey, I quit my job and then I started fable, I'm sure there's a lot more detail that we can get into. So walk us through how did you decide it was time to quit? How did you come up with the idea? Did you get funding? Who were your first employees? How did this all happen?
Alwar: Those are all great questions. So why I decided to quit, it took me like six months to actually make the final leap. My co-founder was ready much more earlier. But I come from a family that no one really has an entrepreneurial bone. So it was it was like a big jump that I was taking from my career perspective. But the reason we decided to start it was just looking at like every part of companies, and we were seeing so many companies, and the way they were approaching accessibility, and it was from such a compliance lens, it was like, oh, you know, something we have to do to check a box, and product teams weren’t really understanding why those compliances exists in the first place. Like why are governments introducing compliance and not understanding the reason why that exists and the needs of people with disabilities and the way they want to interact online. And we've felt that if that bridge has not been made, then we're just going to continue to have this digital divide, that's going to keep increasing. So starting table was just that. It was just like, let's connect product teams to people with disabilities, for them to get that direct insight and learning. And in terms of you know, how we started, yeah, we decided to be a venture backed business, right from the get-go. We weren't thinking of like bootstrapping the business because ultimately, what we're trying to do is we're trying to change the way product teams build products and we want to be able to do that at scale. So, we decided to be venture backed, we did a couple of rounds of financing that has helped us get to where we are. And when it comes to how we even decided upon the solution and the platform that we have. I'm a big believer in like, focus on the problem that you're solving. I think as startup founders, especially when you have a product background and technical background, you can get obsessed with the solution pretty quickly. But I wanted to make sure that we're actually solving the problem, so we even just did like a few proof-of-concept projects, with early customers, giving them feedback directly from people with disabilities, seeing if it actually has impact. And then we build our beta version, which is what we, you know, made into a subscription later on. So I think the goal for us was just to see, does this have impact and if it is having impact, let's try to figure out how we can do it at scale so that every product team has access to it.
Dan: That's really cool, and actually, I honestly think you're the first founder that I'm talking to, that came from a UX background, a user experience background. How does that influence you being a CEO? Or can you see anything that it kind of does to you being in that leadership position, because I think you're the first.
Alwar: It definitely helps, so for the longest time, I just, we just built up our product team so I'm slowly starting to step away from product now, but I've had multiple roles in the product team from Product Manager, product designer, to our QA, to touching every part of it except the strong technical side.
Dan: I see Perry smiling here.
Dan: Perry, was she hands on in the product?
Perry: Yeah, definitely. It's a certain kind of pressure when your CEO is also a QA for everything you build so.
Dan: That's really cool to hear. You get a lot of founders are not from either the technical side, or in your case, the UX side and you can get someone that maybe you can speak at a high level and there's a great vision but doesn't even know how the product works, plus, I bet your board slides are excellent.
Alwar: It sometimes can be a problem when you are a designer, because you, you just pick on the little nitty gritty details a lot. But at the end of it, all of that impacts the end user experience. So I think what I get a lot of joy out of is when we demo our product to prospects and customers. They just love it. They're like, Oh, wow, this is so easy, I can't wait to use it. So that's our goal, just making it as easy as possible.
Dan: That's awesome. So I know you have a co-founder that that's not here today. But what were some of the first types of people that you brought into the company?
Alwar: Yeah, into the company, me and my co-founder, we both have our masters in inclusive design, we have different specialties and mine was in UX. My co-founder’s was very much in providing employment opportunities to minority groups. And one of our first employees was actually one of our testers. Our whole platform is connecting product teams to people with disabilities, and we focus on people with disabilities who use assistive technology every day, to access their computers and their websites and apps and everything. So Sam, who's now our accessibility evangelist, joined Fable as our first tester, and then went on to become our community manager and manage and build a community of testers with disabilities, and now has actually moved on to our growth and revenue side who now, you know, advocates for Fable and helps customers understand the need for accessibility. So Sam was one of them and then we had a couple of people who just need to be the generalists. You need to have people who can wear multiple hats do multiple different roles. so we had a few of our employees who were able to just jump in based on what we needed and then went on to like, specialize either in like customer success, or business ops and do sales and anything that was needed at that stage. So it was Perry on the product side. It was Sam on the community side, and then a bunch of us who were doing generalized work and getting the company started.
Dan: Okay, cool, and Perry are you hands-on developing, do you have a team under you? Where do you fit?
Perry: Back in those days, it was just me. But now there is an engineering team, so we have QA and developers, and I am still working on the code myself as well.
Dan: I always like engineering leaders that are hands-on, still working on the code a bit. so that's excellent. Now, what caught me, you said something about maybe companies that deal with accessibility or have to do something with accessibility, they do it because they just have to check a box like for compliance or whatever. Honestly, that kind of resonates with me more so because a lot of the products that I use, I see they might have some type of accessibility thing to it but it's feels like it's maybe just thrown in there. Can you tell us a bit more how Fable connects people with disabilities to organizations for this research? Who is using the product? And how does it all work?
Alwar: Yeah for sure. So we are SAS platform for inclusive software development. So we have product teams that subscribe to Fable to engage with people with disabilities throughout the product development cycle, and they're able to do this online and on demand. So the way it works is you can have you know, we, if you look at our product, currently, we have more than 50% of our users are researchers and designers we have about, like, I think about 20% that are developers. So we basically have people across the product development process using Fable and getting insights at the right time. The way it works is, customers will subscribe to Fable on an annual basis and they're able to run a certain number of research and test sessions on Fable’s platform on a monthly basis. So you can have a researcher, designer, or developer run moderated session or an unmoderated session, and get insights from assistive technology users on their products. Their products can be a website, it can be an app, it can be a software tool, anything that is on your computer and online, can be tested through Fable’s platform.
Dan: That's really cool. So it's kind of like people that are using it, so maybe you say like a product person, or maybe like, maybe sometimes a development lead or maybe a UX person probably as well, is it more so kind of in the prototyping or before a product goes to production or what stage, if I'm a development team or product person, is Fable typically used?
Alwar: It's for throughout the development process. So you can use our platform as early as the research stages where you just have ideas or you are looking to you know, redesign your product and you want to run some user testing sessions where you want to get feedback from assistive technology users so you can have those moderated sessions, or you can even do it through unmoderated where you can send over like a task. So let's say sign up for discord and you want to know, like, how accessible your signup process is, you can get that (Dan: Yeah) feedback, we also have designers who walk through their prototypes with our assistive technology users and get access to where the issues even before court is touched, can we get some issues right at the beginning and be able to tackle it before developers have built the product? And then we also have developers who come in at the later stage, and then look at it from a compatibility perspective, is like, how compatible is our app across all of those devices and assistive tech?
Dan: So okay, I'm creating a product, maybe my signup flow, that's a good example and how accessible is that? But then you have a community or a pool of people that need that accessibility. Do they get paid? How do you find that pool of people and then connect them all together with the product people on the other side?
Alwar: Yeah that’s a great question. So yeah, we do have a community of testers all across Canada and the states, and yes, they do get paid, we do not believe in free work. Everyone should get compensated for the work they do, and the expertise and skill sets that they offer. That's something that we've actually been very critical about because in the accessibility space, a lot of people like to pay people through gift cards, and none of us earn through gift cards, you know, we get a paycheck and people with disabilities should also get paid properly. So that's a core part of Fable’s mission. The way it works is companies are, you know, subscribing to our platform, they're running the tests, they're filling up the demand. On the other side of our platform, it's like a one-sided marketplace so it's first come first serve. When the request becomes available, any tester that fits the qualification can take it up and provide feedback. and then they get compensated based on the amount of time it took them to complete it.
Dan: To kind of orient our audience about the space in general. So let's say that I'm a product person, lead dev UX person, whoever is interested in improving the accessibility of the product. What's going on with like your competition? Or what's different about Fable? Why should I choose Fable over maybe someone else out there?
Alwar: That's a really good question. So I touched a little bit before on the compliance piece, a lot of companies out there that are offering solution that helps you be more compliant, and just, you know, fit that checklist. At Fable we’re very much focused on making your product as usable as possible to a wider population and a wider range of people, and so we focus on the experiences of people with disabilities and how they find your product and how usable it is. So we're shifting it from away from compliance, to really practicing inclusive design at scale. You have a lot of companies out there that are just consultancies that might just run an audit for you, or they might do the research and then give you the insights. All of that is just making you think about accessibility in silo, it makes you think about accessibility as an afterthought. It's not really integrating accessibility into your entire development process and that's what Fable is doing. We are helping companies operationalize accessibility very similar to design Ops, research Ops, DevOps. We're helping companies practice accessibility at scale, through our solution and we're basically enabling every single person in your product team to have the skills and tools they need to tackle accessibility so that you don't need a dedicated accessibility specialist to take on all of the responsibilities of making sure your product is accessible, because that doesn't scale.
Dan: One of the things that is kind of a struggle right now is around hiring great engineering talent. I don't know if you all are working remote. a lot of the world is working remote. Engineers have the opportunity to work basically anywhere. What's your approach to hiring Perry and, you know, what has worked for you what doesn't work for you?
Perry: So very early on, we hired through our network, we had people that we trusted, and you could get the job done, and we would coax people to come over and join us. So that was a good way to get started, and also to have a team that gelled really well. But we ensured that the process itself is inclusive and that we aren't biasing the candidates we’ll get based on language you're using in our job ads, as well as the process itself. There's some verification of technical skills, but we're not trying to stump candidates and put them on the spot for whiteboard coding, really just more interested in their problem-solving and troubleshooting abilities and also the communication skills and the fact that they're interested in our company's mission.
Alwar: Just a touch on that part. I think for us, you know, yes, it's definitely a competitive market out there. A lot of opportunity is available. A lot of companies are rapidly growing. And I think for us, we've been able to attract top tier talent and I think part of it is also the thing that Perry just touched on last, I think people are wanting to have a job that's just more than a job. It's having impact, it's bringing change. And I think that's a pretty common thread across all our employees where they're in it, because obviously, this is a company that's growing, and they have a lot of opportunity, but they also just see the true impact of the work they're doing, and it’s really driven by that.
Dan: Culture matters a ton right now, it feels like every year that goes on, people are more and more driven to join a company that's actually has a reason why or is doing something to help. And, you know, there's been a lot of changes on the planet over the last few years, let's say. In a really interesting time to start up a company, we did the same thing at Linear B during the same timeframe around the 2019-ish timeframe. Alwar, being a CEO, what's the biggest challenge that you've encountered founding Fable?
Alwar: I would say it's been one of the biggest challenges, but also an exciting challenge. Because we decided really early on with, you know, the kind of company that we're building, we're going to, we're going to walk the talk, and we're going to be an example of what it means to be an inclusive company and inclusive team. And so we made sure we have a diverse team, we have many members of our team who live with disabilities, whether that's visible or invisible, we want to make sure and showcase that diverse teams produce strong innovation and have a strong culture. But with that, the challenge that comes is workplace tools, everyone's working remote, everyone's just digital first now. And there's a lot of barriers when it comes to trying to build an inclusive team, to just the workplace tools that are out there, you know? You have, like, CRMs that are not accessible, you have HR tools that aren’t accessible, you have dev tools that are not accessible. And so that creates a challenge to what people have available internally and that's something that we're constantly working through. There's only just very few applications, workplace applications that are fully accessible. There are very few procurement tools that are very accessible, hiring tools that are very accessible. So if it's not accessible, what are the workarounds that we can do? Because we're not going to not hire because the tools are not accessible, we're going to find workarounds to it. And I think that's been the challenging part of, you know, really trying to build that internal tech stack so that everyone has information available in whatever format they want and interact with each other in whatever format they want. And so we've had to do a lot of you know, custom workarounds for some things. But it has resulted in every single person in the team understanding the impact of accessibility and taking that extra initiative and make sure whatever they're sharing with, you know, each other internally is easily accessible to everyone.
Dan: Well, I think that's a good transition to our next topic, and it's around building an accessibility-first dev culture. So I want to dive deeper into what that actually means. So you know, for people who are listening, who maybe aren't as familiar with that topic, what does it mean to build an accessibility first dev culture?
Perry: I think it's like sort of the opposite of saying that accessibility is an afterthought. In this case, accessibility is absolutely primary. And it's also like a shared understanding on the team that accessibility isn't an extra feature or like a defect that they can backlog. It's just a table stakes dimension of the quality of what they build, and that they kind of aren't finished building what they're doing if it's still inaccessible. And also you need the processes in place, and the right training and stuff on the team to make that a reality.
Dan: So what are some of the changes to a more typical, or maybe old-school development process that you've made, Perry, to ensure accessibility-first dev culture?
Perry: At Fable we've hired specifically for developers who are passionate about accessibility. We really prioritize collaborating with design so that design and Dev are agreeing on what the semantics are, and developers are giving input on the best patterns to use for keyboard access, and it's a very clever process. And also, most of what we're building reuses our internal UI library, which has known good accessibility patterns. And for things that are new pieces of UI, novel UI, and special considerations for accessibility, are called an RPR template. So that everyone is drawing attention to the fact that like, hey, this, we couldn't just reuse this other bit, we have to, you know, whether we're doing something special with focus-handling here, so double check that this is all working as expected. Also, we're really fortunate to either be able to ask for a quick review of work by a teammate who uses assistive technology, or we can submit requests to our own platform for in depth testing by our community. And in addition to that, in terms of just ongoing monitoring, we're building accessibility tests into our Cypress tests.
Dan: That's really interesting. A lot of the engineering leaders that listen to this pod, we talk a lot about metrics or having KPIs for the engineering team. And typically they're around things like cycle time, how efficiently are we delivering new value to customers? Or you know, some quality metrics like code rework, and refactor percentages all the way to the quality of a PR review, kind of like what you brought up with having a template. But now in the world of dev accessibility, are there any ways that you you're measuring, if you're doing a good job or metrics that you use to say we're on the right track or not on the right track with it?
Perry: We do. Like for example, if we have any accessibility related defects, we're flagging them so that we can filter specifically based on those. So that would be something we would watch very carefully. But we honestly don't really let that kind of thing get out the door. Those kinds of issues might be like very obscure compatibility issues with a specific technology as opposed to like, this wasn't built properly in the first place. We just find out about something after it's in production and we hear from a tester like, Oh hey, I couldn't I couldn't use voice input for this text area or something, then we'll investigate that more thoroughly. But I would say that it's more just a part of our work process, and not something that we're monitoring with a lot of metrics.
Dan: Now, Alwar, question back over to you, if I'm a SAS software development company, but I haven't really been thinking maybe too much or enough about accessibility, what are some of the reasons that maybe I could go to a CEO and say, hey, we really need to start thinking about this stuff and, you know, maybe we're behind in it? What would be the reason to do that, besides checking a compatibility box?
Alwar: Yeah, I think that there are multiple drivers for companies to invest in accessibility and we can see that just increasing more and more just since the last couple of years that we've just been around. More and more companies are aware of accessibility and know that they need to invest in it. I think that the latest one that we're seeing, which is the right way the industry should be moving towards, is that by designing your product for the outlier you make your product more usable for everyone. Each of us today use technology that have been designed for assistive technology users first, from as simple as an electric toothbrush, which is designed for people with motor impairments, but this is something that everyone uses now. You have…
Dan: Yeah! Oh wow, Cool.
Alwar: Yeah, you have voice to text was for people with disabilities again. And now we have, you know, Siri, and Alexa, and like dictation, and all of that existed because it was designed for people with disabilities first. So it is already proven that when you practice inclusive design, and design for the edge cases, there is that broader impact. And especially now when companies are trying to be product lead, right, It's all about like product lead growth. How do you prove product-lead growth? How do you make sure products are just increasing usage directly through product-lead growth? That happens because you have good user experience and good usability. Those go hand in hand. So I think executives in just all companies are starting to see the broader value and truth be told, if you just look at just people with disabilities, you have one in five adults experience a disability, one in two seniors experience a disability. This is a pretty huge market that companies are ignoring. And then if they go after this user base, they can tap into, like, new revenue lines that they haven't tapped into before.
Dan: Wow. Yeah, that's, that's really interesting, and totally makes sense. And to kind of just wrap things up here, Perry, let's say that I'm an engineering organization and I want to take a first step to get into being more accessible or having that accessibility first dev culture, what is one of the first things I could do to make a change in my engineering organization?
Perry: I think it's important to invest in helping the team members to build the knowledge and specifically set goals for reports to, for example, complete a course in accessibility. It's an important skill, just like security and performance are for front-end developers. And it should be treated in that same way for professional development. And there are tons of resources online courses on LinkedIn, Udacity. And there are lots of blog posts and talks by experts in the community like Marcy Sutton, and they’re directed to developers, like front-end developers who just need to learn what they need to know to be able to test their interfaces and to build experiences that everyone can use. So I would say that's the place to start is just with building up that capability.
Dan: Amazing. Thank you both for a wonderful conversation. I definitely upped my game in knowing about accessibility and a dev first accessibility culture. Alwar and Perry, thanks for taking the time to sit down with us and break down how Fable is changing engineering culture for the better.
Alwar: Thank you for having us.
Perry: Happy to be here.
Dan: So we like to give our guests an opportunity to close out the podcast with any call to action that you want. What do you want the engineering leaders or team members listening to take away from this conversation?
Alwar: I think it's recognizing that the way we build digital products right now is broken. There is a digital divide between the experiences of people with disabilities and people who are able bodied. And we as people who are part of engineering teams and engineering cultures, it's our responsibility to make sure we change the way we build products and make the process more inclusive, so that more and more people have access to the products that we're building.
Dan: And if I wanted to take the next step with Fable, what does it look like to get started? How do I do that?
Alwar: It's pretty simple. You can reach out to us through our marketing website, which is www.makeitfable.com, and you will have a call with one of our sales team members. We’ll understand, you know, where you are in terms of your accessibility maturity and what's the best way for you to get started, and you can then get access to our platform that you can subscribe to based on your accessibility needs and frequency of testing. And then you'll be able to provide the tool to your product team so that they can start practicing accessibility.
Dan: Sounds great. So everyone check out, makeitfable.com. And a quick reminder for our listeners, if you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcasts, please do so. Reviews are super crucial for a way for our show to get discovered. Also, be sure to join the Dev Interrupted Discord community, conversations like this are going on all week long. I also want to say thank you to more than the 2000 of you who are now subscribed to our weekly Interruption newsletter. We bring you articles from the community, inside information, and weekly podcasts, and the first look at our INTERACT 2.0 event on April 7th 2022. We have linked all of this information in the description below and see you all next week. Perry and Alwar, thank you again for coming on. Much appreciated.
Alwar: Thank you for having us.