illustration for swyx (Shawn Wang) on infinite building

episode 21

swyx (Shawn Wang) on infinite building

Shawn "swyx" Wang is an infinite builder, dual-class CFA, and Developer. Shawn currently works for Netlify.

Tune in to hear Shawn talk about what it means to be an infinite learner and builder and how he uses this approach to further his career.

Topics:

  • Infinite learning
  • Infinite building
  • Javascript fatigue
  • Engagement
  • Fighting feelings of inadequacy

Quotes:

“I changed myself from a financial career...I thought that was a stable thing...I realized that I needed to move on from that…” -Shawn Wang

“You should learn just in time, not just in case.” -Shawn Wang

“If you actively write stuff and put stuff out...that you are interested in, guess what? People come and engage with you…” -Shawn Wang

Find swyx on the internet:

Transcript

Joel Hooks: Alright. Hi, Jen.

Jen Luker: Hey, Joel.

Joel Hooks: So, I'm really keen to learn more about accessibility and I think you might be the person to tell me about it. So, I thought we'd start with just talking about what accessibility is, in terms of how we use the internet.

Jen Luker: As far as how we use the internet, accessibility is the ability for everyone to be able to participate and interact with the internet. So, whether you need to use web technologies to help you interact with it or not is slightly irrelevant. The point is that you can.

Joel Hooks: So, using screen readers, that's part of it. And I think that's something that most people would associate, oh if it's accessibility that means we can use a screen reader, but that isn't necessarily the end of the definition of accessibility. Is that?

Jen Luker: Absolutely not. That's just the tip of the ice burg. That only covers people with enough visual disability to need a screen reader, but there's plenty of other physical disabilities that make how you interact with the web useful for accessibility purposes. One of them is the ability to use only a keyboard. Another one is to have high enough contrast on your website so that people with other vision disabilities like being color blind can see those contrasts.

Joel Hooks: Yeah, so we've had particular challenges with Egghead, because it's video, right?

Jen Luker: Right.

Joel Hooks: So, there are certain challenges there where if I can see the video and hear the video it works for me. How do you even start? What's the minimum that every single website should do? I think that's my question, really. What's the next step if we haven't focused on this at all as an organization or are starting a new software project that we're gonna put out there, where do we begin and what's the course of action that you think people should take?

Jen Luker: So, one of my favorites to start with is the Deque Axe Chrome Firefox plugin. Once you get that installed and you run an audit on your website, you can start seeing what kind of issues that you have. And if you use Lighthouse, for instance, to also test your websites and PWAs, then that also is including the Axe core for the accessibility testing. So, either one of those will do. The Axe plugin actually goes into much more detail and tries to teach you what the limitations are, what the problems are, and the different options for fixing it, whereas Lighthouse only gives you the problems.

Joel Hooks: So, what's Lighthouse, just for folks that haven't heard of that before?

Jen Luker: Lighthouse is auditing that's built into at least Chrome to allow you to test performance, accessibility, whether your website is progressive web app capable, whether you use best practices. It does quite a few audits to verify that your site is ready to go for PWAs, which is like a web app that you use on your phones, but also covers all the other options.

Joel Hooks: So, does a PWA, progressive web app, does that deal with accessibility? Does that address accessibility issues?

Jen Luker: It doesn't, but their accessibility audit portion does.

Joel Hooks: Oh, okay. So, it's related. So, it's auditing accessibility and are you a progressive web app and kinda giving you hints as to what you can do to fix that. So, Lighthouse is a basic plugin. I've seen that. That's on the audit tab, I think.

Jen Luker: Right, it is.

Joel Hooks: And that just runs the Google Lighthouse for us. I actually hadn't even heard of that before a couple weeks ago, and we ran it on our site and were surprised. But it was cool because it gave us performance targets.

Jen Luker: Mm-hmm (affirmative). It does.

Joel Hooks: And I was thinking, performance is important in terms of accessibility in a lot of ways, too, because beyond physical limitations with interacting with the computer, we also have limitations in terms of infrastructure or how fast a page loads will effect somebody that doesn't have 250 megabit internet, which is blazing fast, right? But that's not the norm even for the global usage, I wouldn't think.

Jen Luker: It's absolutely not. If you're sitting in a hotel or a hospital, for instance, and trying to connect to the internet, you're going to learn very fast how easy it is for even first world countries to lose internet access or to have access that's so low it makes everything painful. So paying attention to performance and how your website loads even on very slow internet connections allows you to not only access the people that can afford blazing fast internet, but also all the people that can't.

Joel Hooks: Yeah. Look at our business, right, and I'm always thinking I want this to be more accessible and I want more people to be able to use it. It's a pretty good business decision, but just looking at it. I'd feel bad, right? We didn't have closed captions for the longest time, but we then published transcripts, which aren't as good, but they're better than nothing. I was like, oh I feel so guilty. I was having a Twitter conversation with Marcy Sutton and she's like, well no, you have something. You've made an effort and you've pushed in a positive direction. And I think a lot of people probably feel bad and they feel overwhelmed by the thought of accessibility as this massive huge thing that you have to do. Is it important for people just to make small steps forward if they can't do the whole ball of wax.

Jen Luker: Oh absolutely. Anything that you do allows more people to be able to access your sight and be able to utilize it in the way that everyone normally does. So, every single step you take is helpful. When you definitely run the audits for the first time and you see 300 errors or problems that you're running into, it can be really overwhelming at first. So I try to lay out a few steps that people can take to start with to start making those strides one bit at a time. One of the things that we recommend you start with is your definition of done. If you can include something like JSX plugin, react, ally, or JSX react native A11Y, then you're definitely at least starting to audit while you code, so you're getting a lot of those low-hanging fruit even before you push. And after that, you start with your reusable components, the stuff that you end up copy and pasting everywhere is the code that if you fix it once it fixes it for everything. And then after that you start looking at your individual pages to start fixing the one-off items that the audits start complaining about, and then after that you're looking at content and how you phrase things in order to make it easier for people to understand. So, that's kind of the steps that I recommend to start working towards making something accessible. But definitely start with as much low-hanging fruit as you can. It's amazing how just a couple of changes in very few portions of your website can make it much more accessible for a much larger group of people.

Joel Hooks: Yeah, for us, after we did the transcripts, that was like a step. And then, because we have closed captions now, which we just got to introduce this year and because we had this nice backlog of transcripts, moving to closed captions was actually pretty straight-forward, so we got to progress it. And I'm also taking notes because I feel like this is something that we can actively start doing with your recommendation. You mentioned Axe, and that's from, is it Deque, D-E-Q-U-E, is the company?

Jen Luker: Right.

Joel Hooks: So, the Axe plugin, it sounded like, from what you said, is kind of like Lighthouse but more?

Jen Luker: It is more. So, it's an extension onto either Chrome or Firefox, so it'll be an additional tab and the developer tools, just like if you were to install the React plugin. The benefits, like I said, over just using Lighthouse is that it gives you links within each error and it'll highlight the portions on the page that have the problems, and it'll give you more information regarding what the problem is and multiple solutions to solve it. The links themselves go tell you about why it's a problem and also more reasons to fix it, more ways to fix it.

Joel Hooks: Yeah, I've interacted with some of their articles that they have. And just, I haven't used this plugin. I've used some tool that analyze a page, it feels like. But they have extensive articles on literally how to go in and implement these solutions. It feels like they spend a lot of time and effort building up a catalog.

Jen Luker: Yeah, it is Deque's business model, actually, making things accessible, making accessibility tools and audits. So, it's their business to make sure that the audits that we run are successful and that they don't provide false positives.

Joel Hooks: Yeah, that's great.

Jen Luker: And false negatives. It also means that Axe can only cover between 30 and 50% of your app, depending on how much text there is. In the end, you are always going to have to have a person manually go through with it a screen reader with a keyboard and verify that how a user interacts with it is understandable. It isn't just the technology, it's also the text, it's whether it's understandable, it's whether people can find the flow of the website usable in an easy manner, if it's actually a user-friendly website.

Joel Hooks: Yeah, so that gets into usability that we think about, like making your website efficient. What strikes me, what's interesting to me when you start talking about the words is it almost sounds like how you think about marketing when you're building a site. You want it to be clear and easy to understand and you want people to get what they want how they want it. There's a book, Don't Make Me Think, that I really enjoy that kind of digs into that. People don't want to think, they just want to do. And in a way, these marketing principles are actually accessibility principles also.

Jen Luker: They absolutely are. One of the benefits of incorporating a lot of these accessibility features is they end up helping everyone. One of my favorite quotes says something along the lines of when our library created ramps that got them into the library, it helps not only the people in wheelchairs, but also the couple with a baby and the deliver driver with a trolley and the student on a bicycle. So, those accessibility features don't just help those that require assisted technologies. They help everyone.

Joel Hooks: Yeah. I hear this objection a lot and people will use, I'm using air quotes, the business. The business will never do this. The business will never support this. The business will never provide a budget for this. And I'm wondering if somebody does care, and hopefully people do, how do you get past this objection of the business, which seems to kind of sluff it off onto an inanimate object, in a lot of ways.

Jen Luker: It really does. And though we can effect people, and the people that make up a business are still people and we can remind them of why we need to do this. They can really want to, but they have to report to people, and they have to report to people, and those people have budgets. How do you get this to be a priority? And I want to use an example. Well, we'll go back a little bit before that and say, according to the World Health Organization, about 15% of the population has some form of disability. And those numbers are extremely conservative because they're done based on people that fill out forms, and I had a friend who said my 98-year-old grandmother can't walk anymore, can't see anymore, can't really hear anymore, but if you ask her if she's disabled, she'll say no. So, it's definitely a conservative number. In 2012, the US did an audit, as well, to see how many are disabled here, and the answer came down to about 19%. So, still a conservative number. So we're looking at 15 to 20% of the population is suffering from some sort of accessibility. If your website is accessible, you access those 15 to 20% of people. And if you look at your website in you look at your income and you look at the number of people that are accessing your site, you can say that if your company is $10 million and you increase the revenue by 20%, because you get 20% more people using your website because it's accessible, that makes a $10 million company into a $12 million company just by incorporating some accessibility features. That's not adding any other features. That's making sure you have a high enough color contrast, that's making sure that you can navigate with a keyboard, that's making sure that a screen reader can navigate through your site in some sort of reasonable manner. That's huge. I mean, it's been a long time since I've incorporated a single feature that's increased my company's revenue by 20%. So not only that, but only about one in 10 websites, according to an audit that Deque did, is accessible, which means not only are you increasing your revenue by 15, your readership or usership by 15%, but you're cornering the market on the larger 15% of the population that's trying to use that feature that your website offers. So if you could be one of the 10% of websites that's accessible, you get much more of that market share than others, and then you take that and you add it to the fact that when you incorporate those accessibility features, you access people that have temporary or circumstantial disabilities like a broken arm or holding a baby, and you make it much easier for them to use. So then your entire readership actually has much easier access to get through your funnel. The easier it is to get through your funnel, the more likely it is they'll come back and do it again. So, you're increasing it based on the broader concept of readership and usership, in addition to cornering the market and adding an extra 20% on top of that.

Joel Hooks: Yeah, so it's a market advantage. It can be a competitive advantage for a business. People have a sea of choices, right? So why wouldn't they use the thing that's the easiest to use or even usable at all for them?

Jen Luker: Exactly. It's like they'll use you over anyone else because you're the only one they can use.

Joel Hooks: In my experience, most of the projects I've worked on that accessibility was a push at all was because they had a champion, had somebody that was internal to the company or the project that was making sure that when we talked about done, that accessibility was part of that conversation. Have you had experience doing that? Have you found yourself in that situation where you were a champion for accessibility?

Jen Luker: At basically every company I've ever worked for, I've been a champion.

Joel Hooks: I mean, do you have any advice, then? That's interesting and I'm wondering if you had advice for folks that would like to pick that up and they would like to be the champion for their project for accessibility.

Jen Luker: One of the things I can recommend is pushing back, pushing back from the very, very beginning if you possibly can. One of the biggest issues that we run into is contrast issues. Based on people with lower vision, people with color blindness and just a lot of other vision issues, that color contrast is very, very important. So if you can make sure that you have high enough color contrast, that solves a great majority of problems, and after that, just make sure that as you're coding you can navigate through your website with a keyboard and fix any of those issues as you go. You can also advocate for including accessibility linters into your project to get started, at least. At that point, it makes it easier for the company to do the right thing than it is to do the wrong thing. And I've found that that is the best way to get people onboard, is when it's harder to do the wrong thing than it is to do the right thing.

Joel Hooks: So, not to suggest people should be subversive in their jobs, but management isn't just going along with this, right? They're not going to have any of it, and as a team member at some grassroots activities, can we still add accessibility to the product that we create, to the code that we write?

Jen Luker: Absolutely. You can do that on your own. You just need to make sure that your definition of done before you say that it's done and pass it on to QA or whatever the next step is, that you've passed your own accessibility audits.

Joel Hooks: Right. So, we can build, I can actively build accessible components or build accessible pages and think about that and work on it and add it to part of my project without necessarily having explicit permission or making it a corporate mandate of some sort. I can be in there actively doing these things and running audits and showing the result of that work, I think.

Jen Luker: Absolutely. The company trusts you to complete what it is you say you're going to do, and if you say I've written this component as part of my story, and you pass that on and the component works and does everything they want, they're fine with that. The additional step of verifying that passes accessibility tests, if no one else in the company will do it but you, make sure that everything that goes out the door, everything that goes past you through pull requests includes accessibility audits. You can push back. You can make those PRs that say, you know it would be better if this was able to do this. It would be better if we could make sure that this happened, as well. You can make small use cases for, I was having problems navigating, I was trying to use my keyboard and this didn't work, so I'm going to put in a bug to fix this. And it becomes more of a usability feature than it is an accessibility feature.

Joel Hooks: Yeah, because it might even be a language thing. You suggested this, oh we're not gonna get in that ... Like I'm curious how much you can push back, right? If you're in planning meetings, if you're ... What does it take? For me, with anything I feel like you have to be knowledgeable when you come into it, so you're armed and ready to do battle, or however you want to phrase it, and fight for this cause to be a champion. That's the old-school definition of that: you are a champion and you're hear to fight for this cause. I definitely have never heard of anybody getting fired from a position for really championing the cause of building an accessible, fast, easy-to-use for more people website. Have you?

Jen Luker: No. I've had people get shutdown, occasionally, and say we'll we're not going to go back and change old code. But that doesn't change the fact that you can fix code from here on out. And at the same time, after a while, even old code gets rewritten. And then those are accessible too because they've passed your accessibility audits as you've written them. So, making sure that those thing happen can happen one very small step at a time. It can happen with this one component, it can happen with this one pull request, and everything that you do makes it just a little bit better, a little bit easier to use, a little bit more accessible. That's more than most people are doing now.

Joel Hooks: And that falls into the principle of just writing clean code, for instance. Say we want unit tests, but we don't have any. Where do you start? Well, you write one unit test and you test the thing that you're working on. You write a piece of accessibility, you make this component better. You have to go in and fix a bug? Then can you slide in a little extra code quality, which to me, when you're applying the definition of done, accessibility should be something that's discussed and it should really be considered part of the code quality initiative, as well, right? This is the quality of what we're writing and it needs to be accessible and work right, both for developers as well as end users. It kind of fits into that same category.

Jen Luker: It should, but I also want to task in there an extra little note while we're talking about it. Part of making a solid code base reusable is also documentation. I recommend that any time you have to use an example, you have to write a code example to show how something works, that you make sure that all of those code examples are accessible. I was talking to a friend of mine last year named Nicoline Hubner, and when she started coding she was copying and pasting examples from people that also really cared about accessibility in order to build up her components. And because of the fact that that's how she learned how to code those pieces when she applied for her first job, she used those same code examples and they included alt tags and they included aria tags for certain things and roll tags, and the response back from the company was, wow, you really care about accessibility. And she was kind of confused. She didn't really know what that was, she hadn't heard of it. All she knew was that when you code, this is how it's supposed to be done. And when you're using those examples, you're copying and pasting that off of everything from stack overflow to the documentation from your website, if that's how it's supposed to be done, that's how it's supposed to be done. And most developers just copy and paste, so even in our documentation we can make sure to spread accessibility to any of the copy and pasting that happens after that.

Joel Hooks: Yeah, that makes a lot of sense. So, that makes me kind of think about the idea of being, as kind of let's say a niche programming expertise, where do you see a career as a programmer and being an accessibility expert? Is there a demand for that? Do you see companies looking for that? Does that give us as developers a competitive advantage in the same way that it does a business?

Jen Luker: Accessibility has really started to get a lot of play in the last few years. So, it's still up and coming as things that people worry about. It was code size a couple of years ago, and it was reusability, and now it's starting to move towards accessibility. And I think that it's not because the problem is solved, but the problem isn't being approached, so I think that the more we can allow ourselves to learn how to make things accessible and then just incorporate that into our general code, the better the entire web is going to be. As far as making ourselves more marketable, being able to have that skill is really important right now because of the fact that it is getting a lot of play. So, I think that it is important. I think that it can be a marketable skill. I think that it's still an up-and-coming marketable skill, though.

Joel Hooks: Yeah, it's like wide open to me, in terms of a space where you can blog and have a voice and things even up to conference speaking and this sort of thing, it feels like people want to hear about it and people are really excited and interested. When I'm watching talks on Youtube from conferences and an accessibility expert is up there and they're delivering they're talk, I often hear the audience clap and cheer for specific content. People are excited and interested and I feel like as developers, there's a large portion of us that want to make the web a better place and that's something that motivates us even beyond higher salaries and all that sort of thing, which is nice, too, but it gives you a broader purpose, just the idea that we're building towards, we're part of the solution, instead of being part of the problem.

Jen Luker: Up until very, very recently, it felt like accessibility is one of those things everybody loves to ignore, so everyone was willing to clap and cheer when it comes to conference talks, they're excited that these things are available, and then they go back to their desks and nothing happens with it. It seems that, as of very recently it's starting to step out of great talks from conferences and more into people actually wanting to work with those features and wanting to understand them and wanting to incorporate them. So, it's nice to see that shift. Marcy Sutton actually said a few years ago she applied for a conference with an accessibility talk and the response back was they rejected her because it was a problem that was already solved. And the truth is that the features and the ability to make things accessible is already there, but no one's been using it, so as far it being solved, we may have answers, but if they're not being used, then clearly there's still a problem.

Joel Hooks: Yeah, I mean I know there's still problems. I see the internet and I've been on enough teams to know that it's a problem and there's not enough champions out there and there's not enough people ringing the bell. In the past, I've been guilty of that myself, just kind of sitting there silently and building what we're told to build and not expressing that, but that's one of the coolest things about being a developer to me is there's always something new to learn and something to improve in a way that we can make our trade and our craft better for more people in a way that is accessible, frankly.

Jen Luker: And for those that are listing that aren't developers, this is a job for everyone. Design needs to be involved, product owners and managers absolutely need to be involved. It's definitely an entire business and anyone in the business can be the champion. It doesn't have to be a dev.

Joel Hooks: I agree with that and we need champions at every level for this to really work. It doesn't just work from development. Obviously, the people writing the code have a lot to say in how applications functions, but you're right. If we're not getting buy-in all the way to the top, then it's really just a partial measure, I would say.

Jen Luker: Yeah. Devs can handle the technology, but we can't handle the words that you put on the page. We can make suggestions for how to make the flow and the funnel easier to get through, but that tends to be a much larger business decision than us, and the design that comes to us that we end up incorporating, that also has some accessibility concerns and requirements, from the size of buttons to the size of text, to the color contrast, to how items are organized. We can incorporate that and we can push back on that, but that's also a design decision. So, it is definitely at every level.

Joel Hooks: Yeah, I agree with that. Jen, you've given me a lot to think about. I actually came out with a to-do list of some things, mainly to go try out that Axe plugin. I've tried Lighthouse, I haven't tried that one yet. So, I'm excited to do that one with our site. And I really appreciate your efforts and your continued effort, being a champion for this particular cause, because I think it's important. And thanks again for chatting with me today.

Jen Luker: Thank you.

Joel Hooks: Cheers.

More Podcasts