This past Thursday was Global Accessibility Awareness Day, the perfect time for us to sit down with Webflow developers EJ Mason and Rubin Nic to talk about the work they are doing to prioritize accessibility on the platform for both their clients and website visitors. Baking accessibility into your process as a core value is no small undertaking, and we dig into the lessons they’ve learned and the advice they have to help you ensure your sites are designed and developed as inclusively as possible.

Followup Resources


The following transcript is made possible by Webflow. Do you want to help us speed up our transcribing process? Consider sponsoring an episode.

Well hello and welcome to episode number 62 of the drunken UX podcast. In this week’s episode, we are going to be talking about how the company Webflow is tackling their accessibility strategy to produce a more accessible platform and products for their users. I am your host, Michael Fienen. But I am not joined this evening by your other other host Aaron. He unfortunately could not make it this evening. But fear not, because I have taken advantage of this situation and brought on not one but two of the senior software engineers from Webflow. Ruben Nic and EJ Mason to come on and talk about how they are fostering a culture of accessibility at Webflow. Speaking of Webflow, I want to give them a quick shout out because transcriptions for this episode of the Drunken UX podcast are brought to you by those same fine folks at Webflow. So if you hear anything tonight that you want to go back and reference or or look through, or you can’t get to right now, go to the show notes at We will have a full human edited transcript, there ready and waiting for you. Be sure to go check them out at shoot him a tweet @webflow on Twitter, let them know that you appreciate their support of the show and be sure to check out their platform.

This evening I’m drinking, if you follow us actually on on Instagram you probably saw a couple weeks ago I posted a photo of a little mini cask that I’m working with right now and I had just put in a first fill of some Jim Beam “Devils Cut”. I’m using that right now to season the cask before I actually putting scotch into it. And so I’m giving it a little taste this evening and it definitely even just after a week the edges — because Devils Cut is a very “Grr!”: it’ll it’ll hit you. But after a week in there the sort of candied cinnamon notes come out real strong on the nose. The edges of it are sanded off though just a little bit and you get like the the first taste, you get some cinnamon, some caramel, some kind of almost leathery type flavors out of it. Still strong, still definitely kicks you in the throat just a little bit, and then there’s hot but I’ll give you another I’m going to give it about a month in total in that cast before I swap it out. So we’ll see. I’ll revisit it in a couple episodes and see how it is. Ruben! EJ! Hey, thanks for joining us.

Hey, how’s it going?

Thank you for having us, Michael.

Yes, thank you.

So you two are senior software engineers at Webflow. Tell me first and foremost what that means.

I feel like Webflow has a pretty good definition of what a senior software engineer is: is somebody who is expected to teach and lead other engineers, whether that’s through mentorship or documentation, or just, you know, writing good code. It’s also somebody who is comfortable taking a task on by themselves and bringing it to completion.

Yeah, I would agree with that. I think one thing that would be worth adding is that we often are asked to define a process, particularly around accessibility, because there’s not as much domain knowledge of that at our broader company. So part of our interviews actually was scoping out a task to then complete it and execute it. I went to school actually for writing that was what I went to university for. And you can see I didn’t do that anymore. But it’s it’s been fun to bring those skills back into this field because engineers don’t often like to put words together in order.

Yeah, yeah. No doubt at all. So Tell me EJ, let’s start with you on this because you said you went to school to be a writer, how did you go from that to getting into accessibility as something that you wanted to focus on?

Well, I realized that writing and being creative in general was not going to pay the bills and keep me housed and fed. After having some good luck and some bad luck in writing, I decided that I could find skills that would support me better. And I remembered that I always enjoyed computers and programming as a concept. But I thought it’d be too hard for me because I thought there’d be too much math for me in it, in the field. I went to a boot camp to see how it was, and it turned out I really enjoyed it. While there, I realized that the boot camp itself didn’t really teach accessibility, and someone told me how important that was, and I ended up deciding to teach myself what I could. I was invited back to that boot camp to spearhead our curriculum on accessibility and from there, I just kind of feel finding work in accessibility.

Yeah, very cool. Ruben, how about you?

Yeah. So one of the one of the dark jokes we talked about in the field of accessibility is that companies usually get in for only two reasons: Either they know somebody with a disability or they get sued. And both of those happened in pretty rapid succession for me personally. So when I was in my mid 20s, I was diagnosed with keratoconus, which is a degenerative eye disease. What happens is your your cornea starts to become it gets bumpy and it doesn’t get bumpy uniformly, so you cannot correct it with with lenses. I have a pretty mild form of it. It’s continuing to progress but so far, it’s — it’s manageable. It mainly affects me [since] because the lenses of my eyes are not uniform, they don’t absorb as much light. So at night I’m functionally blind. Which, given my Romanian heritage makes me a really shitty vampire. The other part of that is my previous employer — well, two employers ago — when I worked at the Carnegie museums of Pittsburgh for an internal agency, they were sued. They had an ADA lawsuit filed against them. So they got serious about accessibility and because I was a developer on staff, I got pulled into that and I’ve always sort of had a humanist bent in the way that I’ve approached software. I think a lot of that has to do with the human computer interaction courses I took when I was in college. This, you know — I just sort of I fell in love with it with specifically, you know, working for accessibility and you know, advancing the cause. And you know, making sure that computers are actually usable by all of us.

I’m a big fan of human computer interaction as a field. It’s something that it’s, it’s sort of like, to me, it’s the evolution of everything we talked about when we get into UX and user experience, design and all of that, but it gets into so much more of the deep end of that pool in that regard. So let’s go real fast. I’ve mentioned Webflow on the show, probably, I don’t know two or three, maybe four times in the past, usually in talking about like platforms that you can go to to edit websites on and things. I’ve usually said, you know, this is kind of a platform that wedges itself in, and correct me if I’m wrong, but like Squarespace, Wix; these folks are probably in your competitors sphere? But what is — how do you guys view Webflow as a product? What would you describe it as?

Webflow is a visual development platform that’s oriented toward professionals who want to have depth of control over their websites. So we might recommend Squarespace — we being people on this call — to friends of ours who don’t really want to think too much about the sites that they build, or want to get something simple, and don’t really need control. But webflow differentiates itself because it provides a lot of authorial control over the kinds of content and the interesting choices you can make with design and the other features that has: like the CMS which some of the people in this field do have, some companies in this field do have, but Webflow is exciting because of the depth and complexity it does offer to users.

The way I think I’ve described it to folks too, in the past is Webflow is significantly more friendly on the back end to a normal web developer coming in and saying “Yeah, but I want to change some of this stuff.” You facilitate that I think, better than many other platforms. Is that a fair… I’m saying all this having never used your back end, but just going off, you know, stuff I’ve read over the last few years about you.

I would say that’s fair based on me having never really used much of Squarespace or Wix, [or those] sort of like it, but having been asked occasionally to help people make changes because I’m a web developer. I found it very hard to even give them advice without trying to spend a lot of time learning how to use their account to do something, if that makes sense.

I come from, we were talking about backgrounds a little bit before the show started. And I was mentioning, I started building websites in the 90s. I remember Front Page and installing Front Page Extensions on hosts so that I could upload stuff right — and it was a WYSIWYG! It was designed to let you go in and grab a thing and put it in a place and upload it and have it work. The code of course, that I put out was just garbage. Dreamweaver, when Macromedia still owned that It was very much much the same kind of thing and you’ve got that field. It’s geared towards this idea of, if you can imagine that you can build it, but your emphasis has been outputting code that is standards compliant, that doesn’t make you cringe when you look at it — and I’ve actually been incredibly impressed by some of that. I mentioned at the start of the show that Webflow is sponsoring the transcripts for this episode. I’m not blowing smoke up, anybody’s ass about this, as anybody will tell you, I genuinely am impressed with the kind of code output that your platform has accomplished, even before you started doing all the accessibility work quite frankly.

Yeah, and we really think of ourselves as an abstraction over web standards. We’re not trying to replace the web in any form, or shape. Rather, what we’re trying to do is we’re trying to open up the field of web design and you know, web creativity to more people. You kind of see that with, when you go through when you use our designer, it’s very clear that you’re editing, you know, DIVs, you’re editing SECTIONs, you’re editing CSS classes, you’re editing BUTTONs, we don’t try to hide those things from you. In fact, we’ve seen people use Webflow as an introduction to, software engineering.

I talk about Digital Ocean quite a bit, and one of the things that Aaron and I have always been really impressed with is that Digital Ocean came out and said, “we’re going to be this SaaS platform for doing virtualization and provide you with all these things that AWS provides. But we’re going to also own the documentation space.” AWS is super powerful, [but] anybody that’s ever read their documentation will attest to the fact that they aren’t very educational. And to the point of writing documentation that we’ve already talked about, like, that’s one of those cases where AWS engineers wrote their documentation, and it shows Digital Ocean came in and said, “we’re gonna write documentation that anybody can use,” and it really elevated them as a competitor in that space. That’s along the lines of what I also see Webflow doing. Wix, Squarespace, you know, throw any of these people around, they’re doing their thing, but I also don’t see them putting the effort into education and information the way that Webflow is attempting to do.

I would like to give a shout out to our education team for exactly the kinds of things that you just described. It’s even before I was an employee, I was really impressed by the scripts that they write and the the articles that they write to go with the feature content. I think that they’re doing something really cool with their making it fun, but educational; the humor mixed with the information. I definitely have not seen WIX or the like do those kinds of things. So this is your invitation, if you’re listening, to start joining us in the in the field of writing cool documentation,

What’s that? There’s a name for that that you guys have was it? Was it Webflow College? What is that?


University — Webflow University. We’ll make sure we have a link to that in the show notes too, if anybody wants to go check that out. Because it’s absolutely worth stopping by and perusing. Okay. And so from the standpoint of, we’ve got this platform that’s easy for anybody to use, you go up, you sign up, you’ve got all this documentation to help out with it. Who is it mainly that you guys then cater to from an industry standpoint? Are you getting, you know, downtown bakeries? Are you getting like big manufacturing companies? What’s sort of the gamut of who you see using the platform best? I would say that it’s a pretty wide array of business types, wouldn’t you Ruben?

Yeah, what we’ve really seen is is a lot of like marketing teams. Which was really surprising to me [when] first joining, because I always assumed it was a lot of agencies, a lot of freelancers. But what we’re seeing a really big uptick in is marketing teams owning their marketing pages, and rather than them having to go and bother an engineer for a little, tiny fix of like, “you forgot an Oxford comma over here,” the marketing team itself owns that page and builds that page themselves. We’ve seen that with quite big clients. Some of the marketing teams that we know of that use it for this use case are: Gusto, Zendesk Hellosign, Sketchdeck, Hypertrack — I feel like, pretty big names. We’re really excited about that, and we’re really excited that those marketing teams are now empowered, and that those engineers, are now not tearing their hair out trying to get an Emdash to render in HTML correctly.

The reason this has come up: somebody, somewhere and I’m sure it was on Twitter, shared out an article that came from the Webflow blog, what we’re doing about accessibility at Webflow. I saw this drop last month, I read it, and that was sort of the the instigating event. I read through this, and I’m like, “I would love to talk to these guys about this.” There’s a whole article — of course, it’s linked in the show notes — that goes into all of this stuff that Webflow has been doing; and what they are looking forward to over the next several months; through the rest of the year; and into next year to try to make this platform more accessible. The commitment that was apparent in that writing, you don’t see that kind of language used very often, in terms of just how committed they were to building a product. Not just the product — and this is something that maybe will come up as we talk some more — But it’s one thing to make a product accessible. It’s another thing to make the output of that product accessible, especially when you’re dealing with users. With this platform that like you were just saying, You inherently have to fight this garbage in garbage out — GIGO — mentality that “users can break your system.” Or, not break it, but they can do things that you wish they wouldn’t, so to speak. That’s that is where all of this came from. So first and foremost, go read that article.

There’s a quote, though, that I want to read out of it: “To us. This is both a challenge and an opportunity to make it not only easier to create accessible websites with better tooling, but also to educate both ourselves and our customers on the principles and techniques of accessible design.” It’s a short sentence with a lot packed into it. That is a lot of ground to commit to covering. So that’s what we’re going to talk about through the rest of the episode is all of this stuff that you guys are doing and with an eye towards “How can other people translate this advice to their company,” because one of the things we get, we struggle with constantly, right is having the time to do things, making the business case for it, showing the importance of it and the impact of it. These things are hard challenges, and they can be really hard in the business world to a CEO. Time is money. You know, it’s a throwaway kind of cliche, but it is a reality of working. So that’s what we’re going to try to dig into for this. Now, one of the things that I want to talk about is what you’ve done so far, because It’s not like you hadn’t done anything. There was actually quite a bit that you guys had sunk into this, as far as making it a core company value for you guys now, right?

That’s correct. It’s a it’s a high level directive coming all the way up from Vlad our CEO who thinks it’s very important and has shown that in the way he speaks about it on the internet and the way he supports internal efforts that we’re putting out.

Internal efforts is an interesting point, too, because all of this is great, is you know, to hear. But you need people to know how to do it. You guys have committed internally to making sure that your developers, and designers, and QA folks are, you know, immersed — maybe not completely — but have exposure. Maybe that’s the best way to put it. Right? They they are being exposed to what accessibility means. Right?

Yeah. And and it’s definitely we’re — we’ve committed to it as a company. I think one thing that really made that clear to me is: EJ and I actually interviewed at the same time. We both sort of found out through our trial project that we were both interviewing for the same role, which was very scary, by the way. We both got hired. We were both, you know, very cordial. We were super encouraging to each other. I was impressed with EJs work, quite honestly. And I remember talking to my significant other afterwards, I was like, “I’m not sure if I’m going to get this!”

This was like the moment in The Dark Knight where the Joker walks in and snaps the pool cue and is like, “we’re gonna have tryouts.”

I think what showcases Webflow’s commitment to this is they set out only to hire one person, and they hired both of us, because this is a priority for 2020.

The right time to take advantage of an opportunity is when it’s in front of you kind of thing.


So if you had to estimate right now, of your team, and I don’t know your organizational structure, but from developers and whatnot: how much of your company so far has gotten training in accessibility to some degree or another?

So we partnered with Dequeue systems which offers a course called Dequeue University. If anybody is looking to learn the basics of accessibility, we would highly recommend going and enrolling and taking some of those courses.

I will second that their their stuff is also top notch. Yeah.

I feel the need to point out that if you are someone who has a disability or you identify that way, you see yourself as a disabled person: you can get access to the course for free simply by emailing them to ask for it.

Oh, nice. I didn’t know that. I do know, as I’ve known a few folks that have worked there, [that] their business cards are both printed and in Braille.

Yes, I’ve seen that too.

It’s very cool.

So through partnering with them, we’ve had about 30% of our company takes some form of accessibility course. Some of that is, “how to build accessible websites”; Some of that is “what are the current accessible laws that govern your country, whether that’s the EU or Canada or the United States?”; Some of that is “How do you talk to somebody who has a disability”, right? How do you approach them? How do you make sure that you are not belittling them and you know, treating them as less than human, quite frankly, as is often the case; And some of it is also, “how do you approach the topic of accessibility in writing?”

Some people might say “well 30%? Man, 70% of you haven’t had it.” But 30% is lightyears ahead of most other organizations. That really — I just want to emphasize like how impressive I think that is, to have committed to that from a learning standpoint, and the number of angles that that impacts; like you were just saying that the amount of coverage that gives you is really quite impressive. It builds a culture, that’s what you’re striving for. I shied away because of this point that you’ve got here — somebody had written this in — you’re not accessibility experts, and that’s almost how I introduced you. I’m like, “Nope, that’s I don’t like that phrase,” because you mentioned you’re, you’re trying to build a culture of accessibility. And I think that’s really valuable. To me, anyway, I see it as something that emphasizes, you know, outcomes over issues. To go back to the lawsuit thing: A lot of the times, accessibility problems end up being something of a punch list. “We check the contrast, we check our alt tags, you know, then, okay, we’re done! We did the things!” But that’s not the way accessibility works. It’s like anything else: It’s part of our process and cycle. It’s identifying door handles over doorknobs; It’s about understanding that elevators don’t exist just because you have multiple floors; And it’s easy for me, because it’s easy for everybody. That’s something that I think is sort of a — hats off — that you guys have embraced that idea of what it means to make accessibility be part of a culture.

So the reason why we we really don’t want to use the term “accessibility experts” is because accessibility needs are so broad. EJ has some accessibility needs. I have some accessibility needs. But that doesn’t mean we can speak to everything, right? I personally do not not suffer from motion or animation sickness. So I cannot speak to that. And it’s important for me to be aware of that. I can speak up for those people, but I should never speak over them. Us trying to elevate ourselves as experts, I think would diminish those voices and it would mean that we would become stagnant in what we pursue as accessible because it would be defined by us; by the “experts”.

I think Aaron and I both talked about this on on the show before: One thing we’ve always emphasized is to use a screen reader with websites. Now a screen reader is a very narrow scope in terms of particular accessibility problem. I can install a screen reader though, I can use the screen reader I can listen to it; but my experience with that screen reader is not the experience that somebody who is blind is going to have with it, and when you really sit down with a blind user and listen to the way they use a screen reader, it will absolutely blow your mind how different their experience is. Because even though I can, you know, intellectually kind of understand what I need to do to test that, I don’t have that experience and it’s very hard to emulate. It makes for a barrier that I think is intimidating to people. And it’s one of the reasons why I think we don’t do more in some cases. But that’s okay. It’s okay to ask questions and to reach out to people and things and that’s what I hope. That’s that’s the culture piece I think that comes in here is getting to be okay with asking those questions to folks and listening. Listen to the feedback that you get when people give it to you is a humbling to say the least in some of those cases.

That is one of the goals that we have for our future work in adding education to Webflow university, we would like to — I know I personally would like to — see that as you start writing more articles about accessibility, whether it pertains to Webflow specifically as a platform, or to best practices in design in general, as Ruben was touching on earlier, it is a kind of hollow service if you try to center yourself as the arbiter of what accessibility is, even if you have barriers that you yourself encounter, on the web or off the web.

Yeah. So with what you guys have done, you’ve so far, you’ve been working on microcopy. in the tool. So that’s like little, you know, hints and information as people are using the platform. You’ve done things like make ALT text a bigger component of image elements and brought it to the forefront, which always raises an interesting question to me: We we talk about ALT text a lot. This is almost a rhetorical question, but I sometimes wonder, “do users know what ALT text is?” Like what the word ALT means? I don’t know! Have you guys run into that by chance?

I have all throughout my career at different levels of knowledge and different kinds of teams. I wouldn’t speak for Ruben, but it seems like a very common meaning in our field.


I would like to see us use just “descriptive text”. Let’s just call it what it is. Let’s stop using ALT. ALT is itself a little obfuscating. But that’s a whole other conversation.

Yeah, it is. But I agree!

Let’s see you highlighted that you’ve changed CSS backgrounds. This is actually interesting but also [a feature] that I think is overlooked frequently, especially as we’ve gotten better about how we use imagery and CSS, and the fact that we can do you know, CSS masking now with images and control the shape of things and where things are positioned and radiuses and all of this. But images and CSS can’t have that alternative descriptive text associated with them. You’ve gone through and, because you have got a library of themes..? Maybe I’m using that phrase wrong — layouts?


Components. You’ve been making improvements across the board to pretty much all of those types of elements, right?

We’re working steadily through them as a list of things that are currently in our docket. We do have a layout in the sense [that] there are templates that do offer several components configured together in a certain way to give you a starting point, but we don’t do themes in terms of here’s a set of color palettes for you to use on a site, if that makes sense.

Yeah, okay. Yeah. Do you guys and this is another sort of offhand thought, um, we’ve talked many times about web components on the show, and it’s something that I’m kind of in the middle of right now with some other work. Do you guys leverage web components to any real degree within the back end? Or is that something that so far as you’re trying to stick more to straight up normal semantic HTML?

So kind of. We are sticking to HTML, but recently we’ve introduced something called symbols and symbol overrides, which allow you to create a group of different components that you can then reuse safely across your site overriding certain properties of them. Which hits the same basic set of ideas of web components.


So a lot of our current work is invisible because we want to do as much as we can for the user as possible, for the visual developer as possible. Right now we have it so [that] quite a few of our components, specifically the tab component — which was a tremendous effort on EJ: if you click publish, that tab component is now accessible by screen readers and, keyboard users, and you haven’t had to do anything. That’s been that’s been a tremendous push. Because our platform is so configurable. There is a million different use cases, and I promise you, we’ve hit bugs in all of them. And it has been so hard to make sure that we do not break people’s sites. Because the irony of breaking somebody’s site to make it accessible is not lost on us.

Let me ask you a question about that: So, talking about tabs, because tabs are something that, in visual design, we have defined really well. But tabs aren’t the thing in the [W3C] spec; they aren’t something that exists. So what was the process there in terms of adding [them]? Was [it] ARIA roles? What kind of workflow did you go through there to make those be more accessible?

There aren’t tabs in the spec of HTML, but the but the idea of a tab does exist as part of the ARIA spec. I won’t go too into the weeds here, but those two things aren’t the same. So, in order to make the alignment happen, we had to reassign the roles of the HTML that we produced to represent the pieces of a tab component.

What I would love to know and this is not the time or place for the question, but I would love to know how on the back end side of that you deployed and rolled that out to people? Because I can imagine the engineering required to republish those elements and make them all be in line with your new code.

It certainly is a very impressive effort, the way that stuff happens on the back end. So shout out to our team for doing all the really cool engineering that has made all this possible, because we’re still learning to interface with all their hard work.

Yeah, like you say, you don’t want to break this stuff that is already out there. Because that’s a real quick way to make the clients angry.


Yeah. Quick shout out to Chase Adams, who is a senior engineer on our infrastructure team, for his tremendous patience in guiding and helping us do safe deploys.

Not only now but during our interviews as well, he had to help us both out and we had questions when things went wrong, because they always do, right?

So let’s you mentioned the future:, of course, now you’re writing more content, but down the road you plan on bolstering what you’ve got in Webflow University. But even inside of your editor itself, right, you’ve got some stuff that’s going on there that can provide… is it instant feedback? Is it publish level feedback? How is the tool itself helping facilitate to the editor, who may have no, you know… let’s imagine it’s Grandma’s dumpling shop. She has no clue what any of this stuff means, but your tooling is going to be designed to help facilitate this, right?

There are certain things that we can invisibly fix for our visual developers. But ultimately, there are things that we can’t. Some of these are ALT tags. We spoke a little bit about them earlier that there’s this idea that you can just use machine learning to generate ALT tags. This is a bad idea. Because oftentimes, machine learning can be racist, can be classist, can be sexist, and that’s the last thing you want to do is introduce something that can increase barriers for accessibility.

There are some articles on that that I’ve read; I’ll try to find a couple of them throw them in the show notes now that you brought it up, but yeah. A lot of people don’t realize — and I’ll reuse a phrase: garbage in, garbage out. It’s funny how that applies to machine learning, in particular.

Absolutely. You know, our field has a diversity problem. I think we see that in the training sets that are used. So we see that in the output of our machine learning models. But that aside, all of these things, they have to be done manually. In fact, we believe that there’s currently only about 30 to 40% of accessibility problems that can be fixed through automated tooling. A lot of it is manual, because you’re dealing with humans, right? You’re ultimately dealing with another human being. So you need to connect to that human on a real human level; you need to understand their needs, you need to understand how they use their tooling. So we are trying to create a tool that showcases these errors and then guides you through fixing them whether that’s bad ALT text, whether that’s bad contrast, whether that is not including everything into ARIA regions where people can find things easily, maybe your headers are out of order which confuses somebody using the screen reader. We really want to create a tool that surfaces these, but also teaches you why they’re important.

Yeah, and I would 100% agree with that, especially on like the 30 to 40% line. I’ve talked to folks outside improve. I’ve talked to a lot of these companies that do automated scanning and whatnot and it’s easy to check the mathematical stuff; color contrast, comes to mind. One of the new WCAG specs: minimum hit area needs to be 44 x 44 pixels, I think. We can check those kinds of things really easily, but usability goes so far beyond the strictly mathematical, and that’s where we run into the most trouble. Reading level! Reading level is an accessibility issue and making sure that the content you’re writing is available to people is incredibly hard. Just the fact that you’re building that far is I think, an a testament to how far you’re trying to push things forward for that industry. Let’s go into sort of the tail in the of tooling. To me, this is QA. I’ve been incredibly blessed in terms of we’ve had a couple QA folks on our team over the last few years that have been really tapped into accessibility. So even when we forget about it, they tend to catch things for us, and that’s on accident. They would they were not trained on it. They just also had an interest in it. From that standpoint, I know you guys have a lot of stuff upcoming, you’ve got a lot of things in the pipeline that you’re working on: What advice would you offer in terms of how you would like to see — let’s go back to a phrase — the culture of accessibility. That means designers need to know about it, developers need to know about it, but also your QA folks need to know about it. How would you advise folks to to start folding that into their process?

The question of how to start is always a difficult one, because everything seems important when you have nothing about accessibility in place. But I could tell you what my pipe dream would be, which would be that people who do QA have access to a multitude of devices so that they’re not just testing on Mac OS, not just testing on Windows; they have access to an iPad of some kind; and an Android phone so that they can test talkback, which As the Android screen reader; they can test voiceover, which is the Mac OS / iOS screen reader; they can cover the different browsers, of course, like we’re used to testing for front end, but they can also test all the screen readers or across all the important and commonly used combinations of browser and screen reader.

I’ll throw in there, just a quick plug, and it doesn’t get into like the screen reader level (someday I’m gonna cross my fingers) AWS now has device farm, which is a service you can plug into to do testing and things across multiple browsers and mobile devices and things like that. It’s at least a start. If you don’t have a bunch of devices — we’ve got, at our HQ, a filing cabinet with folders in it, and the folders literally have iPads and Kindles and all of this in it — but device farm is a start towards virtualizing some of that process. It’s at least something but it doesn’t do the screen reader side and some of that, which I think is the ultimate consolation, so to speak, there. … Consolation is not the right word I should use there. But I’m already, I’m now into my gentlemen jack. So I apologize for that.

Yeah. And, you know, one, one thing that EJ and I have talked about a lot is, ultimately, in order for this initiative to be successful; in order for the published websites from the Webflow designer to be accessible: It can’t just be us. And that’s why we’ve really stressed a culture of accessibility. In fact, when we joined, we spent two months just writing documentation encouraging people to do education. Because, while me and EJ can do audits, and they’re fine, they’re not great. They’re just fine. That’s just not a sustainable practice. And so, you know, we’ve really sort of created this culture of like, “Let’s talk about it. If you notice something, let’s come talk about it and, you know, we’ll teach you, we’ll train you.” We’ve had quite a few different people from across the company, just come to us with random pieces of the Webflow product. and even if they aren’t necessarily in our team’s “scope”, we’ve pair programmed and helped a lot of folks understand why maybe something isn’t accessible, and what we can do to get it to that point.

So, at the end of the day, one of the big challenges — and you said something early on that struck a chord with me — which was that your CEO was on board from the start with these efforts and the value, and he sees the importance of it to build a better web; that’s why I make this show is to give education and to help people do better with things. A lot of folks don’t work at those companies. So you have to make the case for why this is worth digging into and why it’s worth spending time on, as a tradeoff. There is an article, that I’ll have linked, from the Google Design….er… well it’s Google Design’s blog, I think it’s on Medium, so I don’t know if it’s an official blog or not. Susanna Zarasky…? I always have trouble with names, but that’s a well-known fact at this point. There’s a good article there that I’ll have linked in the show notes. It’s a little longer but there’s a ton of information in it. We’ll have a couple of others that we’ll reference in some of the stuff we’re going to talk about. It’s always possible to make this case. I think we can dig in a little bit on this, though. I don’t know, for you guys, is this something that started grassroots from your developers and designers, was it passed down from the CEO, how did you guys make the case for the value of investing in your accessibility efforts?

I think that, luckily, the case was made before we became part of the team. Everyone, everyone is a broad term, but, people around us, people who were at the higher levels, the executive levels, and at management levels knew that it was important. They saw hiring us, as individual contributors, as a way to invest in that intention to make a better web. So it’s come from both directions, which I think is the way to do it is to have contributors who know how to help bring up the floor and people who can make decisions to allow those contributors to do their work.

If nothing else, at the end of the day, Section 508 is a thing that exists. That’s a starting point, if nothing else, for a lot of people. We, having come from a university background, that factored heavily into my work; Policy 1210 is Kansas’s statute on it. You mentioned, of course, the whole lawsuit underpinning to motivate people; that’s a terrible reason to get started….but that sort of mitigation can form the basis for an argument in terms of why some attention should be paid to it from the start. There is a note here: “WCAG is not a finish line.” That is, so much more true than people give it credit for. Everything we do is a process; the way we approach accessibility has changed from when I started — I built my first website in, I think 1998? — What we had available to us then is not what we have available to us now. That process of constantly trying to iterate on what we know is, at least, it’s a motivating factor for me in terms of always trying to improve on the things I did before. We joke a lot about looking at code you wrote 2 years ago and cringing because it reflects so much of what you realize you didn’t know. Accessibility works in the same way: TABLE layouts to DIV layouts is the class example I’ll throw out there. That’s the easy stuff though, that’s the easy mentality. What about from an education standpoint. What motivates you guys, or Webflow, or any company that they could dig into?

I’ll take a second to speak personally about this topic, for me. I did mention when we were doing intros, that I have a disability. I’ve been disabled from birth, for my entire life. I have what’s called Cerebral Palsy. I have Spastic Diplegia; that means that my left side is weaker than my right side. I have trouble walking. I am also have low-vision, I use sunglasses so that I can see. So for my entire life, the built-in environment has been sometimes a major barrier to me. When I learned to code, I was ignorant about the kinds of barriers that I was creating on the web. All of this is to say that, to me, the biggest talking point of why this is important and how to educate, and how to move the needle on accessibility in culture and in companies is to talk about Ableism.

That’s a tough word for people, because they feel like it’s this “new-age” kind of thing. But it’s not. It’s all about understanding why the things we do don’t reflect our experiences. I’m 38. I’m a 38-year-old white male. I understand that I live in a world that has benefitted me in a lot of ways that I will never understand. But it requires stepping out of yourself a little bit to understand that other people don’t have your experience and other people aren’t going to react in the way you do now, and understanding that I will not interact with this stuff in the way that I interact with it now. I may lose my vision. I may lose my motor control. I may lose my mental ability to read, or do things. All of these things — the classic phrase, “We’re all temporarily abled”, right? We all are going to experience some level of disability down the road. Baking that into our thinking now will benefit the way we work going forward. Correct me if I’m being unfair in any of that, but that’s just the way I’ve thought about it.

No, I think that the way you — what you’re saying is very important to acknowledge. In fact, Ruben and I had a discussion about this particularly philosophy the first day that we met. I think it’s important to recognize that all bodies have potential for failure, or illness, or injury. But, my motivation has been the fact that there people who are disabled now, who are not having their civil rights met. The WCAG is part of American Federal Law, and people’s federal rights have been violated by the fact that we, as a culture, are not even doing the minimum, which is the WCAG, which is section 508, to make the web a more equitable place.

One thing that we worry about, is if we center it on ourselves or even people close to us, say our Grandmother who uses a walker, then we’re not centering it on the people who need it right now, and we’re not going to see their needs. And because we’re not going to see their needs, we are only going to meet a bare minimum. We cannot push accessibility forward if we focus on ourselves, because your needs are never going to be the needs of everybody.

There’s a topic that is going to come up here, and I don’t know if it’s going to be on the next episode or the one after that (so keep listening! Subscribe, do the subscribey thing!) There’s an article that’s been making the rounds about the accessibility of state COVID-19 sites. That’s a really interesting exercise in that because the people who need the information the most from those, are the people who are most likely to have any number of disabilities, whether it’s motor control, low vision, things like that — it looks at the accessibility of those sites and while the outcomes of it were better than expected, they still had a lot of failings that were important to acknowledge. That’s the kind of stuff that, if I have to build that kind of site, I have to be cognizant of who’s going to consume it, for instance. Or if it’s Amazon — Amazon dealing with all of the online ordering that’s going on right now, and how accessibile is their site? I’ve never really gone deep into the accessibility of Amazon. Quite frankly, I think that would be a great future episode, to see “Can I order an item if I close my eyes all day, and temporarily affect my vision?” I don’t know! Those kinds of things are worth weighing, at the very least. It’s hard to put yourself into those positions some times.

I’m actually going to go back and retroactively change one of my answers. The best way to get into accessibility is just to hear people’s stories. Go on Twitter, search for the wheelchair emoji on profiles, which is how people, in the disabled community, oftentimes showcase that on Twitter, and just read stories. Read how they go through everyday lives. Read about some of the barriers that are placed in front of them for reasons of ignorance, or reasons of malice. Just spend an hour doing that. I think that’s a way better first step than trying to learn it on your own.

How we learn this is an important conversation, because as we’ve talked about before, we’re bad, as an industry. We don’t do a good job in terms of teaching people accessibility from the start. Whether you’re learning it because you look up stuff on StackOverflow, or you’ve taken Web Design 101 in college, or a course in a high school on Intro Web Design, this is not the first thing you learn in any case. But so often, one of the conversations is if you learn to build good, semantic, well-structured HTML from the first step to getting down that road. So often, people don’t learn that. They just learn how to do the thing, and they don’t understand the underpinnings of it or the additional stuff they can do to help it; whether that’s adding ALT tags, or ARIA roles, or things like that. There’s so much more to it; understanding that when someone comes to you and says “Hey I can’t use your thing,” it’s not a criticism of you, it’s an opportunity to expand what you know and what you think about how you build things. Because that’s the goal, we have to always get better; there will always be blind spots — and that’s ok! The web’s a big thing, there a lot of frickin’ tools we have to learn and use and build with, and none of us are going to be perfect at all of it. But at least right now, I think we’re a long way from this idea that if I build a 3-story building, I’ve gotta put a ramp and not stairs, I’ve got put an elevator, and all this. Those things are built in to codes that we just don’t have yet in our industry.

It’s difficult to say how we could move the needle of what the standard level of education is. Of what the baseline idea of what a developer or designer or content-writer should know, because there are so many problems; they all kind of feed into each other like some kind of nasty Ouroboros. But one thing that we can do definitively is to change the way we prioritize other human beings, and to change the way we talk about issues. To me, that goes back to my favorite drum to beat, which is to talk about Ableism. Because if we acknowledge that there is a systemic bias that informs the way that we write education, and the way that we prioritize what people should know to get jobs, we will change the kind of things that they learn, and the kinds of things that people look for when they’re hiring. That will feed back into itself to create a better baseline and a better culture.

Hiring is a big part of that, right? Hire the people that will advocate and stop and push back on things, and acknowledge them when they do it. We need those moments where folks have to fight a little bit, and it’s okay. Be subversive. One of my favorite pieces of advice is “just don’t tell people that you need time to do that,” just tell them that you need more time. They don’t need to know why. If your marketing team wants a thing built, and the thing is complicated, and it needs some accessibility work to be right, don’t tell them that, just tell them it’s going to need 3 weeks instead of 2. More often than not you’ll get away with it. Then, after the fact, you showcase how usable it is and you build that feedback from, whether it’s users, or clients, or whatever the case may be, build that as something to come back with later and say “look at this stuff we’re doing. We’ve been kind of doing it on the side, we know that it took longer, or whatever, but here’s our body of evidence that shows why that was worthwhile.” Maybe that can provide some of that foundation, moving forward. There will be some articles in the show notes that can help with some of that, but…. gentlemen, I appreciate the time you took tonight to sit down with me on this episode, and talk through what you guys are doing. I’ll be really interested to see how this pans out over the next year, couple years — I mean, it’s a process, so it will be constantly be improving. Maybe we revisit this topic here, after a while, and see where you are at work.

Yes, thank you so much for having us, it’s been a lot of fun!

Thank you, so much.

If you’ve been interested in the discussion we’ve been having tonight, if you wanna check out Webflow, they’re a visual web development platform that let’s you design, build, and launch completely custom websites without writing any code. You can combine design, animation, content management, marketing, eCommerce, all of these tools into a single tool that empowers — whether you’re a non-coder, or a coder alike — to ship and promote websites of all kinds in a faster and more cost-efficient, more collaborative way. They power websites for innovative companies like ZenDesk, Idio, Lattice, GetAround, and Dell. If you wanna check them out, go look at, let ’em know — I don’t know if there’s a comment box, or a lead form, but let them know DrunkenUX sent you. But definitely take a second and go check out their website and let them know you appreciate them supporting the podcast.

Guys, again, thanks for sitting with us tonight. I know it takes a lot out of your evening, and we record late at night. I preface everybody by saying I try not to get *too* drunk on the show, I will admit, that I’m now — I’ve killed my Gentleman Jack bottle, so I know I may be running a little long at the mouth, so hopefully they won’t come out in the mix, but first and foremost: EJ, take a second, talk about anything you want folks to know about, whether it’s you, or what you’re doing, where they can find you, what you’ve got going on. And Ruben, you do the same thing, let them know what you’ve got going on.

See, the problem with these kinds of prompts is not that I don’t appreciate them, because I do — but as soon as someone asks me what I like or what I’m doing, or who I am, I suddenly have no idea what I like, what I’m doing, or who I am.

It’s the most on-the-spot thing I can do, so I’m sorry.

No that’s fine, it’s fair — it’s what we signed up for when we agreed to be on a podcast. To be honest, I should know better by now. I should have some kind of press kit for myself, you’d think. Let’s see — I am moderately active on Twitter. You can find me at the handle @codeability. Other cool things I’ve done, I write docs on the web, I contribute to open source software, I have recently written some really cool things for the Mozilla Developer Network, so check out those things soon. Other than that, I tend to just have opinions, yell about them, and try to make the web a better place.

I’m Ruben, you can find me on Twitter @RubenSandwich . I’m slowly trying to live up to the sandwich I was named after. If you have any questions about accessibility, especially if you want to bake accessibility into a website and not tell anybody, like what Michael encouraged, please reach out I will gladly help you do that. I think it’s also important that we are at the beginning of accessibility, because we are at the beginning of understanding who humans are, and what humans need. This is a great time to get into the field of accessibility and really advance it so that we include everybody.

There’s a lot of new writing that is fascinating to read into. If you’re not looking for the word accessibility, but for the word “inclusive design” or “universal design”, those are phrases that can factor into this field. I have to particularly give a shoutout to EJ for the recommendation — our website had an audio player, of course, for the podcast. They said “hey, you know Able Player is a much better, more accessible player than what you guys have now, and so as we were preparing this episode, I got to looking at it and I literally — by the time you hear this episode, if you go to our site, we’ve already released that update to our theme so that you can have access to that. It’s got speed controls, it’s got fantastic keyboard controls associated with it. Again, it’s just a matter of learning, because … what is it… the cobbler’s children have no shoes? I admit sometimes our website is a little bit of an after thought, after all the audio production and stuff is done. I understand that I’ve got some failings there that need to be addressed, and so we worked that in. I actually really enjoy that effort and that advice, so EJ, thank you for pointing that out to me. Let’s see, outside of that, first and foremost go by we said it at the start, we’ll say it at the end — ; Discord is . If you’ve got a second and you are listening to us, whether it’s iTunes, or Spotify, or PocketCasts or wherever you are, hit the Like button, hit the Subscribe button, do the rating thing or whatever — We love it, it helps us out, certainly. Share this far and wide, because accessibility isn’t talked about enough, by any means. Take that time,, because the most important pieces of advice that you could ever take out of anything like this is: Keep your Personas Close, but your Users Closer. Thanks to everybody, EJ, Ruben, Bye-bye.

This episode of The Drunken UX Podcast and its transcription brought to you by Webflow. Logo

Leave a Reply