E13 – Interview with Arthur Gouveia – Part 1

This week, I’m talking with Arthur Gouveia, a front-end developer at Shopify. Arthur discovered accessibility and is working hard to implement it at Shopify.


Nic: Welcome to the Accessibility Rules Podcast. You’re listening to episode 13.


I’m Nic Steenhout, and I talk with people involved in one way or another with web accessibility. This week, I’m speaking with Arthur Gouveia. So hi, Arthur. Thanks for joining me.

Arthur: Hey, how’s it going.

Nic: Pretty good, thanks for joining me for this conversation about web accessibility. I like to let guests introduce themselves. So in a brief elevator-style pitch introduction, who is Arthur Gouveia?

Arthur: Well, I’m a front-end developer here at Shopify. I’ve recently started working here, and I say recently as in two years ago because it just feels like a short amount of time, given so many things that happen when you change country. I’m originally from Brazil. And yeah, I’ve been involved into accessibility really early on in my career here at Shopify, given that I found some space to do so. And been enjoying a lot making sure that not only I have this always in the back of my head, but also like educating some people here. Aside from that, love coffee. Love beer. Yeah.

Nic: Ha. Love coffee and love beer. That’s cool. So, tell me something most people would not know about you, apart from you being enjoying coffee and beer?

Arthur: I think I’m immune to being run over by cars.

Nic: Okay. How does that work?

Arthur: I got run over by a car when I was at the age of six. And yes, I went to the hospital and et cetera. And then again at 17, and yeah. Also didn’t die. So.

Nic: Not dying is a good thing, I think.

Arthur: Yep. It’s something that I try to avoid.

Nic: Yeah. Cool.

Arthur: I’m allergic to bullets as well.

Nic: Is that from actual personal experience?

Arthur: No, not really. I just know that if I take a bullet it’s not gonna be fun.

Nic: Yeah. Okay. That reassures me somewhat, Arthur. We’re talking about web accessibility, and there’s so many different definitions of what it is. I’d be interested to know, how do you define web accessibility?


Nic: Yeah, I like that. It really is about everybody accessing content on any device that is possible. I think that’s great. You said earlier that you were a developer at Shopify. Where does your role fall within the work of what accessibility with all that?

Arthur: Well, here at Shopify, we have some umbrellas that, not separate, but categorize the development work. We have some people working on engineering. We have some people working on UX. We have some people working on prod eng . So that separates the sort-of like the tribes here at Shopify. And within UX, that’s where the front-end developers’ effects are actually categorized. That’s because usually, we are the connection between the interactions that the designers are designing and putting their work to, and the engineering side. So we are that bridge that is making sure that we have as much technical knowledge as possible to make sure that the users interact with whatever we have on the back-end the best way possible. So, when it comes to accessibility, it’s very connected to the front-end side of things, because you are ultimately the one that will be dictation how users are going to be interacting with your website. And when talking to designers, this is super valuable for them, because not necessarily every single designer has experience with web development.

Nic: No, they don’t.

Arthur: So, yeah. And when you come in to bridge that gap and tell them, “Hey, you know what? Hover states are not necessarily going to be so useful in this case,” because, you know, maybe some people are gonna be using tablets or any device with touchscreen due to the nature of their device, or even a set of abilities that requires them to use their hands and touch the thing right away instead of actually moving the mouse. So this sort-of information is usually very new when it comes to the browsers when it comes to most designers. And we basically do some critiques on what may work and what may not, in terms of accessibility for that. And then we find the midway to make that we address everyone’s needs.

Nic: Yeah. That’s good. I was at Accessibility Toronto last week, and somebody said that a lot of the designers send you a design and it’s a little bit like if they were to give you photo of a cake. They tell you, “This is the cake,” but they don’t give you the recipe to make it happen. It sounds like what you’re doing is you’re giving the tools to the designers to be able to write a recipe for you to be able to implement it properly. Is that about right?

Arthur: It does make sense. It does make sense. The thing is that, like, as front-end developers, we can’t just imagine that our main role is to basically execute whatever is best to us. We need to also do the education process as well, so that by birth, everything that we work on, like every single design that is handled, is already having accessibility in mind. That cuts a lot of time of back and forth on decisions, and basically allows us to get to, you know, like, maybe some interfaces that would be completely thought differently if you didn’t have accessibility in the back of your head.

So, we do have this process of almost baking the cake together. Like, it’s very … It’s, usually what a designer would do is, like, they would start working on some of the interfaces. And very soon in that process, as soon as we have like a small sketch of things, they would be presented to not only all the designers, but also many FEDs. And then that’s when we start  tracking. So, “You know what? Like, maybe this one won’t work for people that are color blind. Maybe this won’t work for people who are not sighted.” So, we have this process of going to the kitchen together and bake the cake together.

Nic: I like that. So it sounds like the approach you’re using is making the process faster and reduces a lot of remediation work after the fact and that saves money in the long run. Is that what you’re saying?

Arthur: Yeah. Also, like, from a practical aspect, yes. It does save money because we’re saving time and you’re making your process more effective. It just reminds me of the analogy that I forgot that was basically, accessibility is like a blueberry cake. A muffin, actually. You can’t just bake a muffin and then throw a bunch of blueberries on it and then you have a blueberry muffin. Right? Like, you have to bake everything together. So it’s important that not only we get more efficient time, given that we’re a company that it’s not a not-for-profit, but we want to make sure that everyone’s having a great experience while working as well. We don’t want to have so much back and forth that it gets frustrating. We want to make sure that people are educated and that they understand why they’re doing, why we are discussing these sort of things, and therefore enhance the whole process for the end users and also for us for developing that.

So there’s a lot of education involved, and I’m actually very glad that that happens. Because before working at Shopify, I worked with lots of marketing companies, and usually what I would get is, like, that beautiful PSD with copy layer, copy layer, 47 and whatever, and everything was very disorganized and no one was really thinking through accessibility. And, you know, it was just like a nightmare to work with companies that don’t actually take the time to think through what will be the experience for the end user. So …

Nic: Yeah. How did you become aware of the importance with accessibility?

Arthur: So, it’s good question. I think it goes back all the way to university. I was actually having classes on artificial intelligence, and we were talking about web semantics. So we wanted to make sure that whatever application we were building and whatever document we were creating for the web could be very well interpreted. So that’s when I started looking into semantics, and by semantics I came across term of accessibility. And then making my code more understandable would end up making my code more accessible for other people. Because depending on the technology they would be using, there were specific tags and specific things that I could add to my HTML and the way that I would do my Javascript and CSS that it would allow more people to actually go through, and therefore even allow me to rank up the application or a website on search engine tools. So, it was definitely not something that I was looking for at the time, but I just stumbled upon, and I ended up raising interest on.

Nic: I like how you did not go in search of accessibility, but accessibility found you anyway.

Arthur: Yeah, in a sense. Yes.

Nic: I wish it happened to more people. Maybe we would have a more accessible web if it happened that way. It’s great stuff.

Arthur: Yeah, to be honest … So, I think if you want to get into a more philosophical standpoint, it’s just that we’re not exposed enough, to be honest. Like, we’re just running around, we have our own duties and things to do, and we end up forgetting to look at what’s happening around this. And I say that because it’s like, I feel that here at Shopify we have a really good team, like when we’re talking about the quality of the craft and how we aim to make sure that everyone is getting the best they can, like every end user is getting the best experience they can have. But, it doesn’t mean that it can’t go to an extra level. Nothing is so perfect that it can’t be enhanced, right?

Nic: Yeah.

Arthur: So, there was a moment when I joined Shopify that I decided to follow some paths that I’ve seen here and host an accessibility testing for our product. So we ended up inviting a non-sighted user to come here and do a test with our product. But it wouldn’t be something that would be as mechanical as, “Okay. So here’s a product. I need you to tell me what to fix,” and then we fix. We wanted it to be like much more than that. We wanted it to be a learning experience for people watching that as well.

So what we ended up doing was, we invited around 20 people to be in the same room. They would be allowed to ask some questions, and et cetera, usually towards the end, ’cause we wanted to go through the testing first. But we got like 20 people seeing everything. We recorded the keyboard use of the person. We recorded the screen that they were using, and we recorded their face, so that we could see like the expressions or like any confusion sign on the interface, and see how they interact with the keyboard and how that would reflect on the interface. So, aside from that, we streamed that to other offices so other people in the other offices in Ottawa, Toronto, they could also tune in to see the whole testing.

And the end result was, we got some bugs to fix on our interface. But for me, that was the minimum. Like, that was least good, the smallest of our gains. The important thing that I got was the feedback from people saying, “I have never seen someone that is blind interacting with an interface. I have never seen anyone using a screen reader. I have never seen the struggles that someone may have when going on the web.” So that whole touching aspect of seeing someone struggle with an interface, or struggling to do something that you take for granted because it’s so easy for you, was absolutely the best thing that I see that happened during this. So, accessibility for me is just that people are maybe a little too busy to actually look at what’s going on around them, and that’s why, like, not everyone necessarily cares about such thing.

Nic: Sounds like that experience of having a user interact with your product in the lab where other developers were actually able to see it, that was a really wonderful and awakening moment for you.

Arthur: Yeah. Absolutely.

Nic: You said that perhaps we lack exposure. How do we build that exposure for people? How do we make people more aware of what’s out there?

Arthur: That’s a tricky question. I think you just need to fight the good fight. Like, you need to make sure that you put the word out there. As a developer, we want to make sure that we not only stay in our bubbles and we’re just coding our things and fixing things, but you need to transfer that into an educational process. The thing that I see very often in some companies is that you basically see, like, “Okay, so the interface is not accessible. Let’s make it accessible.” And then you let all the stuff that you need, and that’s it. No one actually gains anything from that aspect. You just … You know, you put a lot of, I don’t know, like [inaudible 00:16:40] labels here and there. You don’t talk to the designers before. You just make sure that you have, I don’t know, the focus apertures are correctly set. You don’t use certain CSS properties. You hide one thing and the other. But that’s it. If you’re self-contained, if you’re not sharing that knowledge, and you’re concerned, there’s no way that this is gonna change. Right?

So, one of the things that I really like to advocate for is that understanding. Making sure that people understand why they’re doing that. Because it’s easy for you to get to their hearts. It’s a very passionate way of seeing things. But then again, like, that’s a little bit of me. But I just feel that whenever you actually expose someone correctly to that, you can get to their heart in a sense. And to be honest, that’s gonna spark the biggest change. After all, accessibility is about being a human and caring for other humans. So it’s something that I often say. Like, accessibility starts with empathy. Like if you don’t have any empathy, accessibility’s just gonna be another feature of your product. And that’s the worst thing that you could do, is like, just do accessibility for the sake of SEO or anything of the kind. A duty because, I don’t know, you’re obliged by law. I just hear that … It’s great that some people are obliged by law, so that we somehow spark with interest so that they don’t get sued, but ideally it should always come from the fact that you’re seeing everyone around you and being a little more aware of how people interact with stuff that you build.

Nic: Mm-hmm (affirmative). You’re talking about creating an emotional reaction to the need of accessibility. And I like that because I’m reminded of a quote I heard that wasn’t directly about accessibility, but basically the quote said something along the lines of, “You can’t logic someone out of an emotional reaction.” And if we can use that kind of approach, where we can actually trigger the emotional reaction, then maybe we’re going to be able to make a life changing pattern of behavior-

Arthur: Yeah. I completely agree with you. Like, if you’re just like … You don’t want it to be mechanical. Like, that’s the point. You don’t want it to be mechanical. And that’s, like, as soon as you understand that there’s like a wide … A real reason for that, and it becomes a reason that you care for, then it’s gonna reflect on your work, right?

Nic: Yeah. That’s fantastic. Thank you, Arthur. I really appreciate that. That’s really thought-provoking, and I think more of us in the accessibility community need to ponder that more. I think it’ll help us going along.

Arthur: Yeah. It’s definitely something that I would love to … Then again, like, I don’t know of many accessibility meet-ups. Well, I, along with you and Dennis, we run the Accessibility Montreal, right? But I don’t go to any other ones. And I don’t know how people are dealing with this. But I would love to know that, more and more, on those accessibility meet-ups, we’re not only working towards, “Oh, this is how you fix things. This is what you need to do to be WCAG WAI compliant. This is what” … No. That’s not the whole point. Like, it’s also like raising awareness. Like, if you’re not raising awareness, if you’re not exposing people to different needs, it’s never gonna happen.

Like, you go to Accessibility Montreal, you don’t actually see a lot of people with different sets of abilities. Like, most people actually have the same set of abilities. Here and there we do have people with different sets, or, you know, that they’re not just included in majority. But that’s the thing. Like, you have to expose people to the real thing. Otherwise it’s just not gonna connect and it’s not gonna move forward like you … You’re going to affect one person, but that person is not gonna affect anyone else. And then you trap the knowledge.

Nic: Yeah. Wow. Cool. What kind of barriers did you face when you were learning about accessibility or trying to implement accessibility? And how did you get over those barriers?

Arthur: One thing that I still face nowadays, and I guess it’s a good and a bad on implementing accessibility on the web. There’s not right way of solving one single problem. You can, I don’t know, like … Let me try to find a good example. If we want to go, say, for menus that on hover, they’re gonna show up and et cetera, there’s many ways that you can solve that menu that has some levels and the words on a hover state. From an accessibility standpoint, you can do many things with Javascript, you can many things with CSS. You can have a crappy DOM structure that you then try to fix with area rows and et cetera. So, the vast amount of solutions that we have to solve one single problem sometimes makes it hard for me. Because what ends up happening is that I am not fully confident of whatever solution I am proposing. In the end, it just becomes like a personal choice of how I tackle this. But the good side of that is that it just leaves your mind open to making sure that you’re always reviewing your solutions.

So … Sorry. There is another person here, Nathan, at Shopify, who’s been trying to learn a lot on accessibility. He’s been doing some courses and et cetera and apply … Like, he’s leading the team’s team, if I’m not mistaken. And he’s always concerned about accessibility and we always talk about, like, how should we implement this? How should we implement that? What do you think about this and that? And often we have different solutions, and we find that both are actually gonna serve the same purpose. So, for me, this is one of the biggest challenges when implementing accessibility, is just that multiple ways of solving a problem. But then again, that’s a good and a bad aspect of that.

And when it comes to … Well, another problem, actually, is that recently I started … I did a talk. I asked you for a letter of feedback on that as well. Dennis as well. And I was looking for good examples of accessibility on the web. Like, good things that we could learn from and try to mimic and, you know, learn any things. And the funny thing is that the only good accessibility, accessible websites that I saw were websites teaching accessibility, and that was all.

Nic: Yeah.

Arthur: It was just a shit show. Like, we tried to going many places to have, like, what is the best accessible website that you know? And then it was so hard to actually have something as good as any accessibility teaching website. And it’s not like that on CSS. It’s not like that on Javascript. It’s not because you’re teaching CSS that your CSS teaching website that you’re gonna have the best CSS website ever. Like, I just know for sure. But, yeah. I don’t know if this is even … if it makes sense. But it’s just very hard to see people who are raising the flags of, like, “Oh, we are WCAG, WAI compliant,” and et cetera. And then you try to navigate on the website and it’s just like, really bad if you’re using a screen reader. So.

Nic: Yeah. I would like to see a showcase of accessible websites. And I’ve seen, over the years, there’s been efforts in that direction. But sites change so fast. And I guess, perhaps, one issue there is that some of those big sites are so complex and involve so many different players. They may have four, five, six internal teams and third-party vendors and all that. It becomes very difficult to synchronize everything to make sure that accessibility is as good as it could be. Whereas maybe those of us who build accessible website to teach and speak about accessibility have maybe less moving parts. How do you feel about that given that you’re in a fairly big outfit yourself? Is that something that might be a problem?

Arthur: So, good question. So here it comes down to the whole education process, right? Like, at Shopify we have a pretty good system when it comes to shipping things to production. It’s not fail proof, but it definitely helps a lot. So every time we want to ship something, we need to have at least two people review the code. And then when the code is reviewed, when the PR is open, the code is reviewed, then it can be added to production. And in the [inaudible 00:26:58], we tried to get people with different sets of knowledges, but that also have context on whatever we’re trying to ship.

So when you’re trying to ship something, say for our checkup area, and you’re adding, I don’t know, like some inputs and you’re adding this title here and whatever, like … It’s important that we have the culture that a FED needs to be pinged in some of the things that are changing on the front-end side of things so that we can go there and not only go with the normal knowledge that any back-end developer would have. Like, most back-end developers that we have do know how to code Javascript and do CSS. But it doesn’t mean that isn’t their line of expertise to know accessibility. Right? So when we have FEDs here, not everyone starts with a great knowledge of accessibility, but they get exposed to accessibility as a concern very soon.

So when we think of FED in some of those PRs, we just make sure that people get educated on what’s going on. like, it’s not like, “Oh, we need to make this heading,” whatever. “You need to bind this input to this label.” It’s not only about giving the guidance itself, it’s actually about educating on the process. And what ends up happening is that that same person that shipped the PR and got some insight from front-end developers is gonna ship another PR at some point doing similar things. And likely what happens is that that person is gonna start with some concerns in their mind. And not only they’re gonna ping you because of that, but they’re probably gonna try to implement something because of the knowledge that you passed on.

So, with this, bit by bit, we have a lot of front-end developers that started as Shopify with little knowledge of accessibility, but that end up being levelled up fairly soon. And because of this exposure and the whole, like, trial and error, and what ends up happening is that you have a team that is highly educated on accessibility. And maybe you have some experts, but everyone in the end has at least a general understanding and therefore a general concern for that.

Nic: I think-

Arthur: Does that actually answer the question? [crosstalk 00:29:27]

Nic: Yeah, yeah. That answers the question. I think long-term, it’s really the ultimate approach is to have all the team members having at least basics of accessibility with couple experts as resources to push things forward. I think that’s a great approach.

Arthur: Yeah. We thought that that’s the best way to scale things. Like, you can have several experts as a company, but we also want to make sure we hire and we create generalists. We want to make sure that people have a broad understanding of things as well, so that you don’t need to be an expert to do accessibility. But you just need to have enough knowledge to have that concern, try to apply something, and ping the correct people on your PR to make sure that they review the accessibility.

We also have internal channels of accessibility where we get in touch with each other asking for opinions and sharing the things that are happening with accessibility. So, yeah. Overall, it’s a culture that was built that is working pretty beautifully.

Nic: Wonderful. Hey, Arthur, I think on that note we’re gonna wrap this segment of our conversation for now. So, thank you for your fantastic answers to my questions and your thought-provoking statements. We’ll finish our chat next week, if that’s alright?

Arthur: Yeah. Absolutely.

Nic: Alright. So, talk to you soon. Thank you.

Arthur: Alright. Thank you very much. It was a pleasure being here.


Leave a Reply