[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today we’re talking about accessibility in tech with Daniel Devesa Derksen-Staats, Senior iOS Engineer on the Accessibility Team at Spotify.

 [00:00:21] DS: Teaching yourself and others about accessibility, it really makes a difference because it is one of those things that if you try to do afterwards, it’s going to be much harder. It’s going to take a lot of time compared to if you make it part of your process.

 [00:00:34] SY: Daniel talks about how he got interested in code and what accessibility is after this.

 [MUSIC BREAK]

 [00:00:46] SY: Thank you so much for being here.

 [00:00:48] DS: Hi, Saron. Yeah, it’s great. Thank you for having me.

 [00:00:50] SY: So what got you started in coding?

 [00:00:53] DS: I don’t really know. I remember, so I studied computer science and back then I was really struggling to find what I wanted to do, but I had a computer at home and I always liked to know more about how the software that I was using was built. So yeah, I decided to do computer science, but till I started my degree, I had never like programmed before. So I really started programing at university.

 [00:01:21] SY: Very cool. And why did you start learning programming? What was it about having that computer that made it interesting for you?

 [00:01:27] DS: Yeah, I guess maybe a bit of cliché about video games. I loved playing video games back then. And that was one of the things that I thought it would be really cool to do, to be a video game developer. I’ve done a bit of that, but not much in the end. But still, I’ve learned a lot and I really enjoyed my career for engineers so far.

 [00:01:45] SY: So you found yourself professionally focusing on accessibility. Tell us what is accessibility when it comes to tech, when it comes to products?

 [00:01:55] DS: Accessibility is basically making sure that the software you work on works for everyone regardless of their ability. And it’s funny how I got into accessibility actually, because when I finished my degree, I didn’t know anything about accessibility. There was nothing in the curriculum. And then I started my career professionally and I didn’t know what accessibility was. I had never heard about it. And suddenly I started working for a startup and then I started doing both iOS and Android apps. I was the only mobile developer in the startup. And for the purposes of making my life easy, I decided to make the app super simple to use what we call native components. So native components are basically like buttons, labels, text fields, things like that, that are provided by Apple in iOS and by Google in Android. And the thing with those native components is that they’re pretty accessible by default. Things start getting off rails sometimes when you try to build those components yourself. So basically I build that up with native components and one day I got a review in the app store thanking us for making the app accessible. And I was like, “Wait, I haven’t done anything.” Try to do a bit more research. But even then, I thought accessibility equals using native components. I didn’t know that, beyond that, you could still make your custom components and made them accessible. But yeah, a few years later, I started working for BBC, and because it was a public organization here in the UK, they really care about making their software accessible by everyone. And they had this accessibility champions’ network and someone told me if I was interested in joining that. So I did. I learned a lot with them and it was really the first place where accessibility was really part of the culture. So it is the first place where maybe Apple manager would encourage us to save time and to take care of making whatever feature we’re working on accessible or maybe designers would do some accessibility annotations in their designs or maybe the tickets would have some specifications about accessibility. Or even like sometimes I would finish a task and the QA would project that task because he was not working with screen reader, for example.

 [00:04:08] SY: So when you got that initial thank you from the app store saying, “Thank you for making this accessible,” did that pique your curiosity about what accessibility was?

 [00:04:17] DS: Yeah, a little bit. So I started watching some videos on talks, so I learned what assistive technology is, for example, what a screen reader is, which is a software that basically lets you use, in this case, the phone without having to look at it. So what a lot of people think the accessible option in apps that used native components, and therefore apps that probably don’t look very pretty or don’t have much character, but that’s far from you. You can do so much to make any app really accessible.

 [00:04:44] SY: So you worked at several companies that prioritized accessibility and gave you experience building accessible products. Do you feel like this has become the norm with many companies or did you just happen to work at a couple of companies that prioritize accessibility?

 [00:05:00] DS: I think it’s definitely getting much better, but I also think I’ve been lucky to work where I’ve worked and the BBC is a great example. I think they had their first accessibility champion network. Then I work for Skyscanner and they’re doing incredible work there as well. And then at Spotify, the same. There was like a big group of people with a passion for accessibility, but sometimes I feel like we’ve moved into the right direction and everyone is on board, but then suddenly sometimes I find that that’s not the case. There’s still lots of awareness to be raised. There’s still a lot of people that don’t know about it, and that’s because of many reasons, right? Like I mentioned that in my curriculum, there was no accessibility back in the university, and that’s still the case in many places. Another example is that when you look for a job description, do you find more often that accessibility is mentioned as a requirement or something that you should know about or something that the company cares about? But not many times, right? And if you think about unit testing or automated testing, that’s something that is always present and the continuous struggle that I have is like waste that the case, because accessibility really is making the thing work in the first place. And automated testing is making sure that whatever you are writing works. So I don’t know how we ended up prioritizing more, making sure that something works than actually making it work in the first place. Right?

 [00:06:22] SY: Yeah, I see what you mean. And I know that one of the ways that you’re helping kind of spread accessibility is that you talk about it. You talk about it at conferences. You do a lot of speaking about it. What made you want to speak about accessibility? What got you interested in that?

 [00:06:35] DS: Yeah. So that’s back to when I was at the BBC. I really liked going to conferences. And so I thought that if I go to speak at the conference, it would be much easier to get my manager to prove and to be able probably for the conference to pay them for the expenses. And when I was starting to write a proposal for a talk, I thought, “What do we do differently here at the BBC?” And the first thing that came to mind is accessibility. That’s the thing that to me was outstanding to whatever I have seen in other companies that I worked before. So I wrote a proposal and I started sending into different conferences and eventually got approved in Appdevcon in Amsterdam. So that was the first time I took to the conference. And I have to say as well that I was really terrified about public speaking and I still am.

 [00:07:23] SY: It’s scary. Yeah.

 [00:07:24] DS: But yeah, there’s this curious effect, right? When you start learning something, there’s a point when you think, “Oh, I know a lot about it.” And then suddenly you go a bit farther and then you’ve realized that there’s a ton of things that you don’t know. So I was lucky as well that I was at that point where I thought I knew a lot about accessibility. That got me to overcome that fear of public speaking and thinking, “Okay, I may not be very good at public speaking, but at least I know what I’m talking about.” [00:07:52] SY: Absolutely. So I know that when you were speaking at a conference, a publisher actually came up to you and asked if you wanted to write about accessibility. What was going through your mind when that happened?

 [00:08:02] DS: Yeah. That was the second time I spoke at a conference.

 [00:08:06] SY: Wow! Only number two. That’s amazing.

 [00:08:08] DS: Yeah. Finished the talk and then the publisher approached me and said that they were actually very interested in having a book about accessibility and if I was interested in doing it. And I said, “I’ll think about it.” Yeah, I really like the idea, but at the same time I thought I would not be able to do something like that for many reasons. Like I’m not one that posting on blogs, for example, very often. I don’t really write anything longer than, I don’t know, a thousand words in a very, very long time. As you can see, English is not my first language as well. Many, many reasons. And again, I was starting to realize that there were a lot of things I didn’t know. But yeah, I also had, I guess, a bit of a fear of missing out. I thought it was like a unique opportunity.

 [00:08:51] SY: Yeah.

 [00:08:52] DS: So I put a lot of work in the proposal for them. I sent the proposal and then it got accepted. So yeah, there was no way back, I guess. And for the next year and something, I did my best to write the book.

 [00:09:04] SY: Who is the book mainly for?

 [00:09:06] DS: Yeah. The book is mainly for iOS engineers. I start from the basics. So you don’t need to know anything about accessibility.

 [00:09:13] SY: But you do need to know iOS engineering?

 [00:09:15] DS: Yeah, you need to know iOS programming.

 [00:09:17] SY: Okay.

 [00:09:17] DS: But you don’t need to know about accessibility.

 [00:09:20] SY: Cool.

 [00:09:21] DS: But still, I always said if you are an iOS engineer in the team, I usually encourage people to share the first couple chapters and the last one with the rest of the team because I wrote it with someone who doesn’t know accessibility. I go through some aspects about what is accessibility, what is important about it, some concepts that are very important to know by anyone that works on software. And at the end, that’s where I go through some of the topics, I think is important to adopt as a team to slowly change the culture of your team and the company to make the whole process more accessible.

 [00:09:56] SY: And what’s the name of the book?

 [00:09:58] DS: The book is called Developing Accessible iOS Apps.

 [00:10:01] SY: Nice. Perfect.

 [00:10:01] DS: So very straightforward title.

 [00:10:03] SY: Very straightforward. I know exactly what I’m getting into. So then you started to work for Spotify. What was your experience like getting a job at Spotify?

 [00:10:12] DS: Actually, it was the second time I tried to work for Spotify.

 [00:10:16] SY: Okay.

 [00:10:16] DS: Yeah, when I got my job at the BBC, it’s funny because I left my previous job and I focused for a few weeks on doing interviews and preparing interviews and trying to find what I wanted to do next. So I interviewed for many, many companies. I got my job at the BBC, but two companies I got rejected from was Skyscanner and Spotify. And I was lucky enough to be able to work on both of them later in my career. And I got a message from Twitter. They told me they were looking for an iOS engineer to work for Spotify in a new project, but they couldn’t let me know anything else about it. That sounded intriguing and I really like the company, so I decided to give it a go. And the thing is I usually struggle a lot in interviews, but I was so happy at Skyscanner that I thought, “You know, I’ll try it out. I’ll see how it goes. If I don’t get the job, I’m super happy here. If I get it, then I get to decide.” [00:11:08] SY: Great position to be in.

 [00:11:09] DS: Exactly. So I guess that gave me a bit of confidence to go through the process. And yeah, I got an offer and decided to move to Spotify.

 [00:11:19] SY: And what did you work on when you got there?

 [00:11:21] DS: Yeah, it was a super fun project, actually. I think the week before I joined, I saw on the news that Spotify was releasing Spotify Kids, which was an app for kids. And I thought, “Okay, that must be the project I’m going to get to work with.” Yeah. I think I quickly messaged the recruiter and I said like, “Is this the project? Can you tell me now?” And yeah, they confirmed it was Spotify Kids. So I got to start the week after they released the app for the first time.

 [00:11:49] SY: That’s pretty cool. But now you work on the accessibility team. So what happened?

 [00:11:54] DS: One of the first things I did when I joined was to see if there were any accessibility groups. And actually, there was one. In Spotify, we have this concept of guilds. So it’s basically a group of people with a common interest, and there was one about accessibility. So I joined and we had, I think, biweekly meetings. So someone would probably give a talk and we would talk about resources that we could share or things we could help around the company to make things more accessible. And because of the great job of that group, at some point Spotify decided to have like a dedicated accessibility team because although it was good, there was a bunch of people voluntarily helping with accessibility. It was quite obvious that having a dedicated team would make a much bigger impact. And yeah, they started the team and I think I was one of the only iOS engineers in in the guild. There were a few others, but they asked me if I wanted to be part of it and I thought it was my dream job, really.

 [00:12:52] SY: Oh, wonderful. So what are some projects that you worked on within accessibility at Spotify that you are particularly proud of?

 [00:13:01] DS: One of the first projects we worked on was to support dynamic type in the Spotify app. Dynamic type is the possibility of selecting the phone size preference.

 [00:13:12] SY: Oh, okay.

 [00:13:12] DS: And you can change it for a whole system or for a single app.

 [00:13:15] SY: Oh, nice.

 [00:13:15] DS: So there’s people that may choose to use a smaller font, but a lot of people actually would use it to have like a bigger font.

 [00:13:23] SY: Right. Right.

 [00:13:23] DS: I like that we talk a lot because there’s so many people using it. Both my parents use it, for example, because they need larger font sizes to be able to comfortably read the text in the screen. And the funny thing about the type is that it’s an accessibility feature, but a lot of people don’t feel like they’re using assistive technology or an accessibility feature.

 [00:13:43] SY: Right.

 [00:13:44] DS: Or they don’t consider themselves as disabled necessarily. So to me, it’s a great example of how accessibility benefits everyone. And if you support, in this case, dynamic type is just mixed up better for a lot of people.

 [00:13:57] SY: Yes. That makes a lot of sense. Tell me about what it felt like to take on accessibility for a product as big as Spotify. Spotify is, I’m pretty sure, the number one music app. It’s so huge. It’s international, millions of people use it. How does it feel to be responsible for accessibility for something so big?

 [00:14:17] DS: Yeah. It’s been definitely an adjustment process for me because I was used to working teams that probably took care of a feature, right? Or a few features inside an app. And everything was very structured, right? Like you plan the work for the next couple weeks and you had probably sprint and you had tickets, and you go through your ticket and when you finish, you just take another one and carry on. But this one is actually less structured, right? Like you get more or less to plan and to decide what strategies are going to work best. And also, it’s very difficult to plan because one thing that we do is basically offering support to different teams. So when a team comes to you and say like, “I’m working on this new feature, I could really use your help to see if we are in the right path, making it accessible or not.” Then they want to get that support as soon as possible, right? Like they cannot wait for a month. So that’s something that we really prioritize, for example. But there’s so many other things. You go through some auditing to see if there are any issues or you may work closely with customer support to see if there are any reported bugs, and you have to do a lot of communication and coordination with different teams to roll out in the future, for example. It’s definitely not a boring job. Every day is different. And that’s one thing that I really like about it.

 [00:15:39] SY: In your experience over the years of building out an accessibility team, building more accessibility features, writing a book, what have you learned about accessibility that has stuck with you?

 [00:15:47] DS: Oh, so many things, I guess. The main thing is at least when I started, I thought accessibility was very specific about people with disabilities and assistive technology users, and I quickly realized that’s not the case. Accessibility is something that benefits everyone. We’ve talked about dynamic dive, for example, but if you think about dark mode, that is a feature that a lot of people use. That could be considered an accessibility feature as well, or subtitles. There’s a ton of shows that wouldn’t be able to watch without subtitles, and that’s an accessibility feature as well. So that’s one thing as well. The other thing is that when I started, I thought about disabilities as a permanent thing, right? Like you either live with a disability or you don’t. There’s also temporary and situational disabilities. So a temporary one, for example, is like I break one of my arms or both of them, and for a period of time I need to recover and I’m not going to be able to use my device with one or two hands, right? But you could be also having a situational disability. I have a one-year-old, for example, and for the last year and a half, I’ve been holding him a lot with either one arm or two arms, right? So I mean using my phone much more with just one hand or having to use it with Siri, for example, because in the situations I couldn’t touch the screen. The same way I usually use my device. Right? So that is also the same idea. Right? Someone said we are all temporarily able, so really in the time of during our lives, we are all going to be disabled at some point in our lives or we’ll get, hopefully, older and our eyes will get tired and we’ll see less clear or we won’t have such good fine motor skills.

 [00:17:34] SY: Absolutely. Tell me about the common accessibility problems that are easy to solve for most apps that maybe we just don’t know that we can solve. You mentioned kind of increasing the font size as one, making bigger text available as an option for people to more easily, more comfortably read the contents of an app. Are there other kind of similar things that we can do that are pretty straightforward that maybe we just don’t know about?

 [00:18:04] DS: Yeah. I think people don’t think about accessibility as something that is very complicated, and in reality, the same issues tend to repeat themselves. So if you fix some of the very basic issues, you are like most of the way there to a very good accessibility experience. And then, of course, like everything defining it and getting it to an excellent point or an outstanding experience is going to be more difficult, but getting it to a very good place is actually not that difficult. So as you tend to tell people that in the case of iOS specifically, start with voiceover, which is the screen reader, because the APIs that we use for voiceover are not built for voiceover, are built for accessibility in general. So usually when you build a very good accessibility experience for voiceover, you are actually making a good experience for people that use the phone with their keyboard, for example, an external keyboard or their voice. For people that use their phones with what is called a switch control, which is a single button to use the device, and the issues that usually you find in voiceover are a lot of times the same. Then the other thing that is very important is to group things in a way that makes sense and to order things in a way that makes sense as well. So an example that I give a lot of this, imagine the Twitter app, right? If you think about a tweet, you have the name of the author, the username, you have the tweet itself. You can have maybe a link, a photo, a ton of buttons, right? Like one for the tweeting, one for liking, one for sharing, so many buttons. So if each one of those elements was accessible, it would mean that for a voiceover user to go from one tweet to the other, they would have to swipe to the divide for every single one of those elements. So it would be very tedious. But if the whole tweet was single accessibility element means that a single swipe brings you to the next tweet and it makes navigation much cleaner and faster and clearer. Right? And then there are some good practices just to take into account along the way. So a common one is color contrast. So making sure that the text has a good enough color contrast with its background. And we think about text that is light gray in a white background is going to be very difficult to read. And then a very common one as well is touch target sizes. So if you think about the button, it needs to be big enough so it’s easier to tap with your finger. Right? A touch screen. Apple recommends for it to be 44 by 44 points minimum, I think. And I think we’ve all been right in that situation where you’re trying to hit a button and you need to do it four or five times till you finally manage to interact with it, right? And for you, it might be just inconvenient and you have to try again a few times, but for some other people it might be just completely unusable if it’s not a good size. And then a very common issue in apps is conveying information in just one mode. And what I mean by mode is color or iconography or just haptics or just sound or just animation. A good example I like to talk about is the shuffle button in Spotify. I don’t know if you noticed that it’s wide one itself, but it turns green when it’s on, but also has a dot underneath. The dot is to add another mode. So now you are showing to the user that it’s on by color, but also that difference in the iconography, and that means that color blind users, for example, are going to have a much easier time finding out that the pattern is on. Just color would be very difficult for them to differentiate between both states.

 [MUSIC BREAK]

 [00:22:00] SY: So I’m hoping that people listening are inspired by all the stuff that you have accomplished and are interested in getting started in learning about accessibility. What are some recommendations of how they might add accessibility to their toolkit when it comes to their coding skills? There’s your book. Any other ways you recommend people get started?

 [00:22:21] DS: Yeah. There’s a bunch of great resources out there from iOS specifically. Apple releases videos every year in their WWDC conference about accessibility. Sometimes it’s about new features, but sometimes it’s like just about good practices as well. And I would really recommend people to watch those because it’s a very good way to get you started there. There’s a ton of talks out there as well by some of my partners who are Novall Khan, Sally Shepard, really great talks about accessibility on YouTube or email. There’s a site and Twitter account called Mobile A11y, and that’s spelled as Mobile-A-11-Y. You’ll find great resources in there as well. There’s a newsletter, Accessibility Apps Newsletter. It’s brilliant as well. And I’m also posting a daily tweet about making iOS apps more accessible with the hashtag 365 Days iOS Accessibility.

 [00:23:15] SY: Nice.

 [00:23:16] DS: And then, yeah, like to get you started to know about making apps more accessible, but another thing that I would like to highlight is that it’s not a one percent job and it’s definitely not something just for software engineers. Everyone needs to get involved. What I said right at the BBC, accessibility was present everywhere in the process. So try to get accessibility in the culture and how your team works. I think a great advice is whenever you have to do a demo, for example, try to do that demo with voiceover. Because that suddenly, yeah, a lot of people learn for the first time about voiceover or know more about it or realize that that’s just another way that users use your software. Things like that. Yeah. Anything you can think about being workshops in your company, lunch and learns, starting champions group, things like that are really great.

 [00:24:09] SY: I’m curious your thoughts on accessibility education because you have a CS degree, but you didn’t learn accessibility in school. You learned it on your own after you graduated, after you were already working. And I’m wondering what are your thoughts on accessibility in a coding curriculum? Does it have a place in kind of that formal training, that formal education, or is it something that you can kind of pick up and teach yourself later on in your career?

 [00:24:33] DS: Yeah. I think both paths are possible, but I’d really like to see it as part of the curriculum of formal education, because in my opinion, accessibility is an integral part of a software engineer job. If you think about it like when you write some software, yes, the UI can be beautiful, the animations can be smooth or it can be performant. But really the main objective is for that server to work. And if it’s not accessible, it’s not really working for a lot of people. So I really think that if that’s the case, an accessibility is just a core part of what we do, it should really be taught wherever anything related to creating software is taught. But that’s unfortunately not the case. Right? So you’re right that you can always learn it yourself as much as you can. And I think another thing is today, because there are not so many developers that know about accessibility, is that a really great way of differentiating yourself a bit? Right? And to be able to contribute, yeah, not just in your team, but across the company. And also on that point as well, like, I don’t know who said that, but I heard once that you should be really mindful of the time you take cutting the tree, but also sharpening your axe, right? Or something like that. I don’t remember correctly. And to me, teaching yourself and others about accessibility is really sharpening your axe. Right? It really makes a difference if the more people know about it and the more people are into it, because it is one of those things that if you try to do afterwards, it’s going to be much harder. It’s going to take a lot of time compared to if you make it part of your process and then is when accessibility sometimes gets this, I guess, bad repetition of means something that is hard and that takes a lot of time. It’s just that you left it to a point in the process that is just too late. And I think that happens with anything really. But if you make it part of your process, it’s really not that much more work.

 [00:26:39] SY: I want to touch on something you said where it can make you more competitive, if it’s something that you know, since most developers don’t know about accessibility. In your experience, how do employers view accessibility? Do they see it as a value add to the company? Clearly, it’s a huge value to the users, but do companies, do managers, hiring managers, do they see the value of accessibility skills?

 [00:27:02] DS: Yeah. That’s a good question because I guess if that was really the case, you’d see, as we said, accessibility be more part of the job descriptions and the interview processes. Right? And that’s not usually the case. And yeah, I don’t know if that’s because a lack of awareness or just because they think that there’s not that many people that know about it. But definitely I think you can show that you know about it in an interview process at some point. And I think it’s definitely something that is going, again, to differentiate yourself from whoever individual is going to remind you, right, that because you mentioned accessibility or because you have that knowledge that no one else has shown in the process. But it’s true that, unfortunately, sometimes I hear about a lot of people that still need to sell idea to their companies, their managers that accessibility makes sense from a business perspective as well. And I’d love if we were past the point, but I hear from other people that that’s not always the case. So yeah, I think it’s good for, if you are passionate about accessibility, it’s good for you to be able to talk about that as well. Right? And to let them know that 15% of their population is with a form of disability according to the World Health Organization. And that’s over a billion people in the world. And as a business, can you afford just ignoring all those people? Or I think there’s a study here in the UK, the spending point from people of working age that have a disability is worth, I think, something like around 250 billion pounds. So it is a huge market. And the thing is that, unfortunately, because not much software is accessible, again, if you make it accessible, you are differentiating yourself as well and people with disabilities are going to notice that. And probably the only thing they can do to achieve a task is to use your software, right? Because there’s no other that’s accessible. And finally, they talk about in their communities and I say, “Look, I know I wanted to book a trip and I could do it in this place or I wanted to do this thing and I was able to do it with this app,” and suddenly other people will start using it as well.

 [00:29:15] SY: And that’s something I want to understand a little bit more is how we prioritize what kind of accessibility we want to address. Because I think that when those of us who maybe have heard about accessibility think about it, it comes in the form of usually screen reader, right? Making the font bigger, contrast, that kind of thing. But there’s many different ways that people can experience barriers to using technology. So when you think about the different accessibility needs of different users and the range can be very wide, how do you prioritize what to address? How do you prioritize what type of accessibility need is more important and takes priority over others?

 [00:30:01] DS: Yeah. We mentioned that there’s so many different assisted technologies, right? It might be overwhelming sometimes, especially when you’re starting to learn about accessibility. So there’s a couple things you can do. In iOS, what we usually do, as you said, is to focus on voiceover on the screen reader. I think that’s mainly because it’s the first assistive technology that was supported in iOS. So people just got used to voiceover compared to voice control or switch control, for example. But the other thing is what I mentioned before as well, that the underlying technology is the same for all those assistive technologies. So if you get to implement a very good experience for voiceover, it’s very likely that it will be a very good experience for keyboard usage, for example, or switch control. That’s why we tend to focus on voiceover. But you are right that there’s things that you can do to improve a voice control experience, for example, apart from what would you do for voiceover. So another thing you can do is to, I guess, try to find statistical data that shows which assisted technology is more used or could be more used in the industry or in the market that you are trying to tap into and then focus on that, for example, but it’s a really tricky issue because a lot of people try to approach this problem by collecting data about their users. And that’s a very tricky thing to do. It might not be ethical. It might not even be legal. And they would completely discourage people from trying to collect any data points to their users to have, for example, a disability, but also it can drive you into the wrong conclusion. For example, imagine that you try to find how many users in your app use voiceover, right? And you may find out that these are 0.0001% of them, but maybe it is because your app is not supporting voiceover really well in the first place, right? So why would any voiceover user use your app? Kind of like if Europe is not supporting Chinese, maybe you find out that you don’t have many Chinese users. Right? Because they may not understand it.

 [00:32:14] SY: Right. Fair. Makes sense. What are some non-obvious accessibility needs that are pretty important but we may not think about? If we kind of put screen reader, color contrast, those kind of assistive technologies as the ones we might think about, what are some other ones that might kind of fall below the radar?

 [00:32:37] DS: Yeah. I think cognitive disabilities is something that not many people think about. I saw a talk recently that talked about anxiety, for example, and how deceptive patterns may make users very uncomfortable or cause them anxiety. And one of the examples was like when you’re trying to book a hotel, some sites will say, “Oh, there’s only one left or there’s 20 people watching it at the same time than you.” [00:33:04] SY: Yeah. It’s so stressful.

 [00:33:06] DS: Exactly. So that’s stressful for everyone, but for some people might be really like a course of not being able to proceed with the purchase or having a really, really bad time. Just one thing. Also, a lot of times, for example, how do you write your messages in your app, like the copywriting in your app? A lot of companies try to be very jargon-y and funny and use phrases. That can be an issue for a lot of people that may just get lost on what you’re trying to really say. And not just people with some cognitive disabilities, but also people that may not be having English as their first language, for example. So yeah, I think those are definitely a lot of things that are overseen a lot of times.

 [00:33:55] SY: Coming up next, Daniel talks about accessibility awareness, speaking about accessibility and the various types of accessibility that’s out there after this.

 [MUSIC BREAK]

 [00:34:14] SY: So what would you like listeners to take away from this episode, folks who might be thinking about accessibility for the first time or maybe only the second time? What do you hope people take away from this?

 [00:34:25] DS: I’d hope for people just to understand that this is just part of what we have to do and to find ways of making it check on nature and just integrate it in their processes. Try to push their teams on working, on making software more accessible. There’s times where people may think, “Oh, this thing that I’m working on doesn’t need to be accessible.” Right? Like for example, I’m doing a prototype and I’m just going to try it out with some users and see how it goes and then I figure out how to make it accessible. And if you think about it, that’s not fair, right? Because if you want to get feedback from users, I guess you want to get feedback from all your users, including people with disabilities. If you didn’t do that, you may get to a point where, yes, you have something that kind of works, but it’s very difficult to make accessible. Or even better example I think is when you work on software that is used internally in your company, a lot of people may think, “Okay, I don’t know anyone with a disability around the company, so I’m not going to bother to make it accessible.” But what that means is if you are trying to hire someone and someone with disability tries to get the job, then you’re going to have a harder time hiring them because it means that if they start the internal tooling of the company is not going to be accessible. So you are not setting in the map for success. And that’s really unfair. So yeah, I’m hoping really for people to understand that accessibility is just a core part of what we do and it needs to be part of our process from the beginning to the end.

 [00:35:57] SY: Absolutely. Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Daniel, are you ready to fill in the blanks?

 [00:36:13] DS: Yeah, I think I am.

 [00:36:15] SY: Number one, worst advice I’ve ever received is?

 [00:36:18] DS: I’m going to cheat a bit on this one. I’m just going to tell about something that happened to me, but I think it would make sense. So basically when I was at school, one of my teachers told me once I would never be able to get a university degree, and I think I was really lucky because I’m usually quite insecure. So I think that thing could have just wrecked me and made me believe that I wasn’t able to do it, and somehow I understood that that’s not the case. And probably what they were trying to do is to motivate me somehow on thinking, “Oh, the person told me I cannot do it, so I’m just going to do it to prove him wrong.” Right? So I’d say never try to motivate anyone in that way because it can really go the other way. Right? And you can really destroy someone with having that.

 [00:37:09] SY: Absolutely. Number two, best advice I’ve ever received is?

 [00:37:13] DS: To speak up and take care of yourself. One example is when I started working, one of my first engineering managers, who I think it was the least experienced manager I had, but actually one of the best I had. One day I was on holidays and told me, “When you come back, I just got a raise for you.” You’re going to like, you know, like maybe there’s something you just presented, I told the company, you’re doing an excellent job and I told them that if they don’t improve your conditions, you’re going to leave for Google or something like that. But he also told me like, “Don’t think this is what usually happens. Whenever you move on and go to a different place, you are going to have to fight for these things yourself.” And that’s true. Like a lot of times if you don’t speak up, people are not going to read in between lines or really understand what you want for.

 [00:38:07] SY: Number three, my first coding project was about?

 [00:38:10] DS: Yeah, I think my first coding project that I released out there was used by people was a video game for the iPhone called Unlocked. And you had to solve puzzles that were simple, but you had to do it really quickly and it was such a fun experience.

 [00:38:28] SY: Very cool. Number four, one thing I wish I knew when I first started to code is?

 [00:38:33] DS: That there’s multiple paths to get to be a software engineer. And that’s something I really like on your podcast, that shows like so many different experiences. Right?

 [00:38:41] SY: Absolutely.

 [00:38:42] DS: People that achieved becoming really good software engineers in many different ways. I went to university thinking that that’s was the only way of getting there. And in my career, I’ve met so many people that never studied at university and were excellent professionals, for example. Not saying that you don’t have to go to university is a great thing to do, but definitely not the only way. And yeah.

 [00:39:04] SY: Absolutely. Well, thank you again for joining us, Daniel.

 [00:39:06] DS: It’s been great. Thanks so much for having me.

 [00:39:12] SY: You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.