Managing Accessibility in Web Development | #7 Joran Quinten

Transcript of the podcast

Video version of the podcast is available on YouTube.

Summary

In this episode of focustrap, Tim Damen and Joran Quinten discuss the importance of accessibility in web development, sharing personal and organizational successes in improving accessibility standards. They delve into Joran's experience writing a book on web applications, the challenges of balancing accessibility with security, and the role of design systems in fostering inclusivity. The conversation also touches on the impact of legislation like the European Accessibility Act (EAA) and the importance of user testing with individuals who have disabilities. As Joran transitions into a management role, he reflects on the importance of staying updated with technology trends and the ongoing challenges of ensuring accessibility in software development.

Accessibility is a pressing matter that needs attention. - Joran Quinten

Chapters

About Joran Quinten

Joran is a Web Tech Lead and Engineering Manager at Jumbo, with extensive experience in frontend development. He is the author of "Building Real-World Web Applications with Vue 3" and has a passion for connecting technical disciplines with design to create impactful user experiences. With his background in design systems and component libraries, Joran bridges the gap between creativity and functionality in web development.

Beyond his technical work, Joran is active in the development community, serving on conference program committees and sharing his knowledge through speaking engagements. He brings a problem-solving mindset and a touch of humor to his collaborative approach, always seeking innovative solutions that elevate the accessibility and usability of digital products.

Follow Joran Quinten on:

• LinkedIn
• BlueSky

Improving accessibility can lead to significant organizational success. - Joran Quinten

Join the Conversation

New episodes will be released regularly!

Ready to join us on this journey? Subscribe to focustrap wherever you get your podcasts and stay tuned for upcoming episodes that will inform, inspire, and help you contribute to a more inclusive digital world.

• focustrap on Spotify
• focustrap on Apple podcast

Together, we can make technology work better for everyone, one conversation at a time.

Transcript

TD: Hello and welcome at Focus Trap, a digital accessibility podcast. My name is Tim Damen and I'm joined by Joran Quinten, web tech lead, engineering manager at the Jumbo and author of the book Building Real-World Web Applications with Vue 3. Welcome Joran.

JQ: Yeah. Well, thank you. It's great to be here.

TD: Great that you joined us online in the online studio. I'm hoping to have some nice conversations about web development and accessibility. Yeah, thanks for the time.

JQ: Yeah, no problem. Always happy to talk about anything web related and accessibility is a pressing matter sometimes. So it's an important topic to highlight.

TD: Yeah, for sure. Yeah, that's why we started the podcast, of course. And yeah, great to have you on. We've met already also in real life in New York, of all places. That's great. At the JS Nation front-end conference, which was very nice.

JQ: To Dutch people meeting each other for the first time in old Amsterdam or new Amsterdam, it's a strange coincidence.

TD: Yeah, indeed. But we had some fun at the conference and also at the speakers' dinner. It was a really nice experience.

JQ: Yeah, it was. You gave a talk about accessibility topic, I imagine. I can't recall what it was about, to be honest.

TD: Scaling accessibility. More on the topic of accessibility in big organizations. Of course, many more than 10 or 10 to 20, 50 engineering teams. It gets harder to take one line or take one position on accessibility and have the same level of accessibility.

JQ: Yeah, yeah. I get that. Well, with every added line of communication adds a lot more complexity to any organization. Yeah.

TD: Indeed. Yeah. We just entered 2025, which is nice, of course. Looking back at 2024, There are some successes you can share, maybe some successes personally, but also as an organization.

JQ: Yeah, so I would say on a personal level, the conference that you mentioned was the first time that we organized it in New York, New Jersey actually, but we call it New York, which I think was a great success actually. And I'm not doing the heavy lifting there. I'm on the program committee, but I had the benefit of being able to join the conference regardless. That was one of the highs of last year. And I would say the book that you mentioned was, well, I'm not going to plug it now because it's already outdated since I'm writing a book about technology that always has a very short shelf life.

JQ: But it was fun to do. That was the first time that I did something like that. It was published in I think January, February. I sold more copies than I had set my own target for. So that was, yeah, I would say a success as well. And on a professional level or from, let's talk about this from the Jumbo perspective, it's fun that in 2022, so that's a couple of years ago already, we got a scathing report about accessibility. And since we're now on the accessibility topic, I dressed up a bit of those details of the trajectory that we entered at that point.

JQ: So our e-commerce solution was fatted and the report that was generated was just not good. So 2023 actually stood in The main focal point of that year was to get rid of that bad rating. We did a lot of effort with the whole development department to increase our accessibility. Actually, in 2023, there was a new report generated based on our e-commerce solution. Then we came out, I think, somewhere at the top five. So I dredged up some details, not all of them. But we improved our situation by miles. And I would say that last year, 2024, we started to not just solidify that position, but also take some additional steps in incorporating the accessibility aspect into our e-commerce solution.

JQ: And I think that's within the context of this podcast as well, that's also one of the highlights of last year. There were others, but I would say that this is the most relevant one to talk about today.

TD: Yeah. Yeah, no, definitely. It's something we can get into in more detail, I would say. Yeah, sure. Yeah, really nice to hear about you guys at the after the work that you did. But speaking about the book and yeah, so the target was, you saw more than you set as a target. Some numbers.

JQ: Okay, you want numbers. Okay. So the goal of writing the book for me personally was to publish a book, which was step one. And then I figured, so, As soon as I've done this, I will be happy if I sell, say, 50 copies once it's done. This will not turn into a profit, but I was doing this in collaboration with a publisher, so I wasn't the one taking the risk, which was fine by me. But by the end of the year, I did some counting and I exceeded 300 copies over the course of a year.

JQ: So I'm very pleased with that, particularly because my goal was not to sell books, but to experience the whole book writing process. And this was just sugar on top. I think it's in a way, it is rewarding to see that the effort that I've put in resonates at least with a couple of people enough, at least so that they are willing to purchase it which was fun. And I would also, yeah, I think what I also, but this was not the last year, but the year before was a sort of a yes year where I said yes to all of the challenges that came into my life.

JQ: And one of them was writing a book. And I think that's also a nice experience. And this is then again, the reward of taking chances and trying out new things and experimenting with or stuff you've never done before. I think it's cool that you were then able to A, do it and B, exceed your own goals. Maybe I was a bit cautious, probably, because I wasn't really sure how it would land. But either way, I exceeded my own expectations, which I think is something to celebrate, regardless of your initial goals. Yeah. It was fun. It was fun writing it.

JQ: Also very difficult and time consuming, but also fun.

TD: Yeah. Yeah. About how time consuming are you speaking about? So writing a book would be one of my future goals as well. I think it would be awesome to do that. What do they say? A man should write a book, plant a tree, build a family.

JQ: Well, I'm already there, I think. Nice. Yeah. But yeah, it does take a lot of effort. I think I started, it took me, I think about nine months from start to finish. And then the beginning was trying to figure out content. And luckily AI was already a thing back then. So I could use it to generate a couple of projects and ideas. And since I had no idea what to talk about, I figured I want to make this a book which I can give to junior developers or aspiring web developers and that they can build some sort of portfolio during the course of the book so that you have something practical and tangible almost by the end of it.

JQ: And that would be something that you could showcase to future employers or possible employers. And that would be then the value that you get out of following all of the assignments in the book. The reason I took that approach is because I have also read tutorials, books, and whatnot where you do these. The To Do app is a very famous one. It is, to be honest, it's part of chapter one or two. Not sure. But it only gets you so far and it doesn't really net you anything apart from building a simple app. And I would like to see that you build a couple of apps while gaining a bit more understanding.

JQ: So the apps that you build can become more and more complex. And these could also be apps that you could use in your daily life and having them connected to something that you could potentially do like a recipe generator or something that helps you in figuring out what the problems are that your users are facing and how you can come up with solutions. And I hope that I have stressed in my book enough that everybody has freedom to make it their own project. But yeah, so that went backtracking to the initial question. So this was about generating lots of content and lots of projects and ideas, and that took me a while.

JQ: And then it was, I scheduled every Tuesday evening, I believe, and on a weekly basis, it took me every week a couple of hours to first, you need to build the app yourself to figure out what are logical steps and what are steps that you could potentially follow as a newcomer to technology. And then it's after you've built the app, it's deconstructing it and breaking it up into little steps. Then it's about writing all of those initial steps. And that takes a lot of time, to be honest, because at least I'm I have a background in front-end development, so I'm not used to documenting.

JQ: That might also be very typical. I'm not speaking for everybody, but writing is hard for me in the context of an app. But this time I had to write how it works, why you're building it, why you're building it like this. So that was a new perspective, which was In hindsight, it was also very helpful for me to get a much better understanding about the technology that I was using. I think they also say if you can explain it to someone, you have learned or mastered it. I wouldn't consider myself a master, to be honest.

JQ: There was always so much to learn. But being able to explain it, at least make sure that you have a solid understanding yourself. So every chapter took me a lot of time and effort. And then it gets to your reviewers and then you get a lot of feedback and you have to revisit all of those old chapters and content that you've written and try to figure out What the heck was I thinking at that point in time? Or where was I going? And again, that new perspective, again, teaches you all a new experience to see how indeed those junior developers or junior readers would interpret the text that you think is unambiguous.

JQ: But if you read it for the second time, it's hard to get straight what I was initially trying to, well, the point I was trying to get across. So yeah, it was fun. I would not say that I would do this again anytime soon. Maybe a long-term future because of the investment and also if I'm Honest, I already said this, but the shelf life is really short. So the value that I created is short-lived. In two years time, it will be outdated and not really usable. But that was fine for me because the goal was not to build something that lasts for ages.

JQ: The goal for me was to experience the writing process, which I think is a good way of approaching things as well, to set your goals, to think that work for you and don't be bothered by everything else that you can add to it. Because sometimes you just can't manage and it's okay to do it as best as you can do with the amount of effort you're willing to put into it. Yeah.

TD: Yeah. Wow. It looks like a great process and a process where you can learn so much from. And I think releasing a book is one of these milestones that I would go for myself as well in the future. So great to hear all about it and the experience you had and the reasons behind it. Yeah, thanks. And looking forward, 2025, what is 2025 going to be for a year? Terms of accessibility, of course, also the EAA is coming up. A lot of companies are making moves right now. How do you see this?

JQ: Yeah, so I was Not necessarily cautiously optimistic, but pretty optimistic about the arrival of the, not necessarily the necessity of the EAA. But I think it is good to have that stick and not necessarily always the carrots to motivate people. So I was cautiously optimistic, but I learned today, I saw it on social media that this is not in Europe. The White House pulled their accessibility guidelines, I think, from their governmental website. And I thought, oh, shoot, this is going in a completely wrong direction, regardless of politics or Yeah, that's, that's a different, dangerous topic to, to dive into.

TD: Oh yeah. Also, I'm sorry to interrupt you, but the new website that they released is also not accessible. I checked it. And I think in terms of like Trump and his movement, I think accessibility is, is going down under the flag of like moving against the EI, which I think Yeah, of course, it's definitely not a great thing, but it also, to me, accessibility stands on its own.

JQ: Yeah, I have opinions about the political implications and politics in general, but it is indeed something that stands on its own. If you make an analogy to buildings, we build doors that fit people, right? Not small doors that fit half of the population. So what is happening or what seems to be happening, so I want to be careful in how I put this or phrase this, is that people choose excluding people over inclusivity. Yeah, the bottom line or the mindset that you should have when thinking about accessibility is being inclusive to everybody. And that is a perfect in line with what I think was originally the vision of the web is that it is something where we can connect with anybody in the world.

JQ: And anybody means anybody. So again, the being inclusive comes back in this mindset as well. And excluding people, talking about accessibility, sometimes people get excluded, not on purpose, but just because lack of awareness. And that is something different than at least on purpose excluding people or groups of people even. So while I was being cautiously optimistic about the developments in the European Union, I also see very alarming signals in other parts of the world. But yeah, it is what it is. And that's something that we can change, unfortunately. But what we can do, and that's where the EAA or Europe or any company anywhere in the world, it doesn't really have to be a European organization or anything.

JQ: But by setting a good example, setting the right examples, I think that would be the only way for us developers, people contributing to the web, to set the right example and make sure that whatever we build gets a bit more inclusive with every line of code we commit. It might be a positive outlook, I'm not sure. But that should be the aspiration of everybody who makes their money on the web.

TD: No, definitely. And on that note, Last thing I will say connected to politics, but of course there can be policies in place and not in place anymore in the future. But at the end of the day, it's also about web developers themselves and companies and a lot of other people putting in efforts to build accessibility. For example, I learned about how Microsoft is approaching accessibility. They have a policy that if they do business with a company and it's software related, that this company adheres to the BACA standards and they will actually test it themselves. So when you get into like an And like a hiring stage, but then for, for companies, um, you have to show that you are accessible.

TD: Otherwise you know, relation can be, can be built. So that's, that's actually a great example on how things can work as well. It doesn't have to do anything with, uh, with, uh, with politics. So.

JQ: Exactly. Regardless of, I think you said it correctly, regardless of politics or rules or regulations, yeah, you should all strive to set an example and make it the best possible web for everybody.

TD: Yeah, no, definitely, definitely. Talking about EAI, so the deadlines this year, end of June, is also the YUMBO gearing up. You guys have been doing a lot.

JQ: Yeah, we are on track, I believe. So I moved to a different team since the beginning of this year. So that means that I have less eyes on our progress. But from what I see, we are either already compliant or we are very close to doing so. So it was, I think, in hindsight, a good thing that in 2022, we got that wake up call. Let's call it that. And we had enough time to put our efforts into building up our accessibility. And the lesson or a lesson here is that once you set it up, you have a solid foundation.

JQ: And then it's much easier to expand on that foundation or improve upon it. So that would be one of the key takeaways as well, is if you spend your time at an early stage, make sure that you have all of your, what's the expression? have it all checked and make sure that it works and that it is compliant, that it's much more easy to follow stricter guidelines or to improve upon it or to do whatever you like as long as you keep that baseline in place.

TD: Yeah, no, definitely. So you moved into a new position, but you were doing a lot of things for the design system. Yeah, correct. Yeah. And yeah, so how important do you think an accessible design system thing is in terms of being accessible?

JQ: Yeah. So what we do at JioBo is we have a sort of a, well, it's not a two-pronged approach, but we have two solutions that work very well in tandem if you look at it from an accessibility standpoint. And one is that what we used to have is a lot of micro applications that were used to make sure that we have an e-commerce solution. And what we did over the course of last year and the year before to try and solidify and merge them into a single front-end platform where still teams have their own space to work in.

JQ: But the foundation is the same. One of the benefits there is that people have to spend or spend less time on maintenance, dependencies, updates of all of that and all of those regular chores. the pipelines and all of the DevOps stuff as well. So that's all being handled by sort of an abstraction layer or we call it a frontend platform. That helps in freeing up time for developers because they spend little or less time in doing all of those activities which don't really add value for their business capabilities. They just cost time and resources and money.

JQ: So having more time means you can spend your efforts where you want them. And the other topic or solution that we have is our design system, indeed. And that has been around for quite some time, to be honest, but not always in the same capacity. It started out, and this is, I think, a regular occurrence as a component library, simply something where developers who are building and recognizing repeating patterns, Developers are lazy or smart depending on how you look at it, but you store them in a central repository or place where everybody can use them.

JQ: You don't have to build that button or the button is always the most tangible example, but you have to build it once and then you can use it anywhere. So that the design system started or component library started to mature into a full-fledged design system. We can confidently say that at this point. I think a couple of aspects are very important looking at it from an accessibility point of view. Well, Component Library was mostly a tool for developers, not necessarily UX designers, UI designers, or accessibility experts for that matter. It was more of a place where you could exchange code.

JQ: But since we've started to call it a design system, For us, it also means that the whole design and development cycle is part of that design system. So UX designers, UI designers, and developers, they work together in solving these challenges. And that helps because what we had before is that sort of a micro waterfall in in our agile workplace where a design was built and it was transferred to a developer, and then the developer picks it up, translates it to code, and then it's put on production. But what we now see is that there is much more of a thought process before any code gets written or anything gets designed.

JQ: So we're first looking, what should this pattern achieve? What should it do? And then you can take a look at all of the aspects that come into place with building these patterns, like performance, security, and obviously accessibility too. So we can, from the ground up, start to include it. And as I said earlier, if you do this at an early stage, you can benefit from all of the efforts that you spent at that point in time. And you can just expand it as soon as you start to iterate on your component or on your pattern.

JQ: So I think those two solutions are both the front-end platform where people can focus on building and delivering features, as well as the design system. They have helped us in focusing our efforts into adding value and not necessarily doing the maintenance, doing the tech depth or there is of course still maintenance to be done and tech net to resolve. But I think this is handled now in a much more focused way, a much more manageable and also much more visible, which also helps in keeping track of the things that you have to do. And I think there's a final piece of this puzzle to be added.

JQ: And that's the way that we contribute to our design system. So when we had this component library, this was originated from the idea, well, basically not necessarily from an idea, but how we are working together already. So teams who collaborated closely and are building on neighboring features, for instance, a shopping basket, there would be multiple teams having an interest in that thing and they would collaborate and they would together sit together and decide how should we build this pattern? How can this pattern be used? Who do we need to talk to? Well, those people, if you want to make changes, especially breaking changes.

JQ: When we moved from our component library to our design system, we also took into consideration the way that we want to keep maintaining this and keep it up to date. What we have devised is, we're not the inventors of this, we've just taken a look at what other people are doing. But we have implemented a contribution model where we have everybody from every development team able to contribute to the component library and that's really helpful because in some cases those are the experts that have most in-depth knowledge about those certain business capabilities or patterns and they are the ones that you want to be in control of a pattern.

JQ: and in order to make sure that we have a solid foundation and also allow teams to move at a certain pace because when teams are building new features, they don't want to be waiting on a design system team for them to build their components for them so that they can use it. I'm not sure if that model is applicable in any organization, to be honest. But it depends. Either way, what we did is we made sure that the basis, the foundation, is the responsibility of the design system team. They can get resources from other teams as well if they need it.

JQ: And depending on how close or how much a pattern is shared across teams, There are a couple of tiers. So we have a shared tier in our design system. And then in the case of the basket, the people or the teams who are stakeholders in the basket, they are part of that tier and they decide, they are the owner, they decide how it should be treated. Other people can still make contributions. They can still use it, but they are not responsible because they are not the experts. So that's our next tier. And then we have our, it's a team tier.

JQ: It's just something that only exists in a team. And this could be either in the form of a POC or just a feature that only lands in just one team. And that of course can eventually over time be promoted to a shared tier and then new rules come in effect for that component or pattern. But that's, I think, the way that we are making sure that everybody is involved in the design system. The design system is used by everybody, and everybody's up to speed. And we can also focus our efforts on not just the design system, of course, also building business features and doing other crazy things.

JQ: But this allows us to get more focused. The Frontline platform gives us freedom to pursue new opportunities. Yeah, so those two things with that implementation, I think they are key to the successes that we're now having. Yeah.

TD: Yeah. I can imagine this looks like a very refined way of working. One with the development platform you talked about, taking things out of the things to do out of the engineering teams to so they can focus on building features, not on maintaining the product so much. And the way you guys have set up the design system and Contribution tiers, I think it's also very, very refined. And it's very interesting to get to know also the different strategies. Some design system are closed off and then only responsible by the design system teams responsible to do all the changes.

TD: Some take the more open, completely open way of working and what you guys came up with is more like a hybrid version. There's also room for some customization.

JQ: Yeah, indeed. And I think that freedom for customization is also key in making sure that people don't misuse the design system. It shouldn't be a bottleneck. It should be something that helps you move faster and not something that you should strictly follow for the sake of using the design system. And I do have to add that indeed this approach, we have designed or implemented this approach because we were taking a look at how is our organization now structured and what works for our organization. So when I said earlier that closed system, I'm not sure if that works for any organization.

JQ: It depends on the organization, of course. It might work. But yeah, I think the design system should make you move faster. So it should follow the way that you're already working. And that can be in a hybrid model. It can be in an open model. It can also be in a closed one. All of the options are probably always valid. But in our case, this hybrid one was the way to go. And of course, in practice, what you see is that still people sometimes cut corners, and that's fine. You need to have some elbow room in order to build features sometimes.

JQ: So we don't, we said from the beginning, we're not the, our design system is called Compass. We're not the Compass police. We're just, well, the Dutch police is, what's the, yeah, they're very helpful. Let's put it that. So in that way, we are the police, but we are the helpful police and not forcing you to use something in a certain way. We want to make sure that you want to use it in a certain way because it helps you move faster. And if it doesn't, then you have a very good reason of not using it.

JQ: And that's fine also.

TD: It's actually great reasoning behind some more platformy style applications. very relatable in terms of also my team and my team at the ABN, what we are doing and building. Strategy is to make it as good as possible so teams want to use it. while not telling them that they need to use it. So they really want to use it because it saves them time and effort if they would have to do it themselves.

JQ: Yeah, it works. Or at least from my perspective, if I build a side project, I don't use our Jumbo design system, But I tend to grab an existing component library and not build everything from the ground up, because you have to think about so many edge cases and supportive features, especially for side projects where you are very limited on time. That would not be the wise choice, I would say. So that there you already, this is like the big contrast of being a single developer, so very small resources, amount of resources, sometimes with very big dreams.

JQ: But then you see that it works, that that is the correct motivation.

TD: Yeah, no, no, indeed. These great, great insights. Thank you. Thank you. And so currently you, you transitioned into the role of engineering manager as you currently are doing at the YUMBO. So how is, how is it going for you? Is it like a full-time management role or also some engineering still?

JQ: Yeah, so it's a hybrid role as well. What I'm doing is I'm managing the parts of the customer service teams. These are very important teams for Jumbo. One of our propositions is that we put the customer first. So in that regard, customer service is highly important. And it's not just the customer who buys, it's also a store service. So whenever stores have questions about orders, deliveries or whatnot, they also access our service center. And for those digital solutions, what we have, a couple of teams ready to help them and build new features that help them even more.

JQ: But I'm also doing some development on the side, and I think that's fine. In the future, I would probably want to move into a more managerial role, but this hybrid is a good way to transition, I would say. And on one hand, I was in the design system team and I had a lot of fun in building out the strategy, the vision, the components. So I do miss that sometimes and I don't have time to do that anymore. But this is a new challenge. This is also very, very fun, very much fun. And yeah, trying out new things is also a way to grow.

JQ: So I think it keeps life interesting as well. Yeah, it's fun. But yeah, I do a bit of both. Still a bit of front end, using the platform, using parts of the design system. But we're also building some POCs, so not always using the design system. And I have to admit that this situation is also very interesting as well, because now I'm on the other side of the fence. I'm now not actively promoting the design system. I'm now seeing how it gets used by people. And I'm now one of those people who tries to use it.

JQ: And then you realize that you can run into different issues or quirks that need addressing. Luckily, I have a direct hotline to the former team. So that helps, but it's valuable for them as well because it provides insights on actual usage. And that's always very, well not always, I think in our organization at least, it can be very difficult to track how it is actually used, how it is actually perceived. Yeah, so that's also, well, always a challenge, I would say, in getting the right metrics and being able to trust them and making sure you're going in the right path or right direction.

TD: Yeah, I can imagine. One thing that I, so personally, I'm also more transitioning into more management-related roles, still doing engineering tasks as well. But to me, it is also a bit scary. transitioning more to a management role. Cause I always, actually, I always want to stay connected to, to engineering and content development. Cause I have the feeling, okay, if I completely let go of it, then I'll also, uh, then then I think at some point I would just lose so much knowledge and being able to manage engineering teams is also... You need to have this knowledge, I would say.

TD: Yeah, to me it's always a bit double. 100% management, not engineering anymore. It's a bit scary to me.

JQ: Yeah, I get you. And that's how I started as well. Now I have to say that if you are familiar with the paradigms and techniques at a certain abstract level, then you probably know enough because you should not build the solutions for your team. You should help them. They are the experts. It's a big transition because at that point they are the experts and you should be able to trust them to come up with the right solution. They probably not always will. But that's the same goes for you. So if you were still a developer full-time, you would also sometimes do something that's not directly relevant or make mistakes.

JQ: But that's also part of the learning and development process because you learn a lot from the things that you did wrong. Um, but yeah, I, I completely understand what you're saying. I was, uh, on, uh, on the same page, but now I'm more into, um, it's, it is also okay to, to let go a bit. Um, but it's, yeah, it's like getting rid of your training wheels when riding a bicycle. It's, uh, development is very familiar. Uh, Very comfortable sometimes. You can do that on your side project still, Tim. That's, that's okay.

TD: Yeah, of course. Just keep the side projects up there. Exactly. Yeah. But in terms of like, okay, now in a management role for a team, how would you go about like, sometimes you need to balance out, okay, here we are now prioritizing this a little bit more and over this force quality needs to stay high. accessibility now is coming up as legislation, so we need to be compliant there as well. For example, we also need to take care of our security, and there are probably backlogs full of new features that we need to create, balancing out certain priorities.

TD: Is it something that you approach?

JQ: With difficulties sometimes, but balancing the priorities. Luckily, we do Scrum, so we also have a PO that is also partly responsible for the priorities and the prioritization. But indeed we have to make sure that we have a sound product and that can mean that you need to spend more efforts on filling some security gaps or closing them or you need to scramble because indeed EAA is on its way and we're not compliant. But this is the ongoing ongoing task or activity actually that you need to be constantly aware of what's coming up. What are we doing right now?

JQ: Where do we stand? And with us, I would say that for roughly 80%, I would say that the product owner is in charge of the product, which I think makes a lot of sense. I would be more in charge of the team to make sure that the team is healthy in a healthy spot. So we have enough knowledge in-house, we have enough procedures, we have enough resources to do our job. Yeah, but I think the challenge then is still the same, but this time it's with people and not necessarily with software. But this is about talking to a lot of stakeholders, people involved, getting grips on regulations and getting as much information as you can.

JQ: to make a decision. And again, sometimes that's not the good decision in hindsight. As long as it's the best decision and at that point in time, I think you're good. Yeah, but yeah, it's an ongoing balancing act. Sometimes it's easygoing, sometimes it's challenging, but yeah, that's also what keeps life interesting, right? To alternate between busy periods and some quiet time. Yeah.

TD: And in terms of like knowledge, of course, your engineering team also needs to keep up to date with the latest knowledge variety of topics. I can imagine how are you approaching this staying up to date with the latest trends, but also with accessibility, for example.

JQ: Um, do you mean for me or for the team? Yeah, for both. Yeah, both. Yeah. Okay. Uh, yeah. So for me personally, what I do to stay up to date is to, uh, make sure to, while I'm on social media, I try to, uh, That's maybe also one of my goals for 2025, to lessen my time spent on social media. And I'm mostly active on, or not active, I'm opening blue sky every now and then. I'm probably most active on LinkedIn, but also not very active in contributing. But there you see trends emerging and I think that helps in figuring out what you can or need to focus on.

JQ: For me personally, I always have a Notion file in front of me with topics and I paste links into that file or I add them to my bookmarks and I Sometimes I read that, sometimes I forget about them completely. And I'm somewhat in the conference circuit as well. So those are always good opportunities. Well, I privileged in that sense that I am part of the program committee, that I see all of these topics submitted in my inbox mostly. It's interesting. And there it is very easy to identify at least trends. AI, machine learning, everything related to machine learning or AI is a hot topic and it will be for the upcoming year, I suppose.

JQ: I'm also a bit skeptical about actual usage. Now, there are some good use cases, but that's a different topic altogether. But yeah, so staying up to date is sort of part of what you would do on a daily basis. And sometimes information comes to you, sometimes you need to grab it. And as for making sure that the team is up to speed, I think, so from my point of view, it's a matter of having eyes on who knows what and if that knowledge is evenly distributed. Do they know enough? And if the knowledge is not evenly distributed, make sure that people do regular pair sessions or whatever they need to do in order to transfer some of their knowledge.

JQ: and as part of having them gain new insights, new information. I think an interesting story here, or story, anecdotes, is what we are doing now on the accessibility topic. That's also why I'm thinking about it, of course. is inviting people over who are the experts, but also who are actual stakeholders. So people with, for instance, disabilities and different kinds of disabilities as well, to have them in our UX lab and make sure that people who are stakeholders in building features Understand in practice what happens with somebody who has disabilities and has different means of operating software or has challenges with operating our current software because then you know what you need to address.

JQ: So having those experts over and having those workshoppy things, that helps as well. And it's of course also up to, I would say that any individual who works in web should be able to know how he or she or them gains knowledge and stays up to date. It's part of the job. Your job is not to write code. It's to write, speaking for developers at least, it's not writing code. It's writing the best code at that moment in time. And in order to be able to do that, you need to have knowledge about what's going on right now and also what's going on in the future.

JQ: So it's also individual's responsibility, I would say, and I think everybody who after a while still works in tech is probably capable of doing that. So that's probably not necessarily a concern, but sometimes people do need to be pointed in the right direction or need an extra hand and that's okay too. Yeah.

TD: Yeah. Wow. Great. Yeah. Definitely something to, to, I would encourage all of the listeners as well, integrate users in your, in your testing flow as well. The end users, of course, and users with disabilities into this group, start testing with your very valuable and setting up these sessions can be extremely rewarding as well. Because especially for large organizations, sometimes it's harder or sometimes you are so far away from the end user as a developer or product manager or designer that you tend to forget Um, that you are building, uh, together with humans for other humans.

TD: Yeah. And this is, I think one of the, um, uh, should be remembered, um, and, uh, taken care of, um, in an organization, especially when you are, your organization gets bigger and you start, start making money as well. You could spend some time in user research and testing with your end users. Yeah.

JQ: Yeah. And I'm not sure if you do this. I know that some organizations do have these keyboard Fridays or changing the settings for your device so that you have to use it as a temporary disabled human. We don't do this at Jumbo. can provide some valuable insights in how your software is being used by a portion of your visitors. So that's always something that you can keep in your back pocket to explore on a rainy Friday.

TD: Yeah, great tip in terms of these testing yourself. I would encourage everyone to turn off the brightness of the screen fully. Start up the screen reader and use only keyboards to navigate your application.

JQ: Yeah. And then also be aware that the way that you're now experiencing it is still very much wide off of what a permanently disabled individual would experience because they are, of course, much better practiced in using these tools. But at least it highlights some of the struggles that you could encounter.

TD: I think a very nice exercise for everyone to and experience a little bit of what it's like using the application that you are building with a disability. Yeah. Yeah, exactly. Great. Okay. So for the last questions, I'm going to ask a series of three questions and I would like you to try to answer with yes or no. Okay. Would you release something to production if it's not secure?

JQ: I want to say yes, but it happens sometimes that it's no. Yeah.

TD: All right. Cool. Would you release something to production if you know that it's not accessible? Same. So if a product is finished, is a product finished if it's not accessible?

JQ: So honestly, no, it's not. It's like a car with no seat belts or, but yeah, sometimes you do cut corners in practice. And I think it's, so yes, this happens and it should not happen, but we all know that it does happen. I think it is good to be aware when this has happened. And also, this is something that we all need to talk to our product owners about, that you are delivering a car with no seat belts or that it's not finished. And there needs to be follow-up at least. And it needs to be addressed as soon as possible.

JQ: And sometimes you do deploy a feature because of time constraints or other types of pressure. It happens. We all know it. But then at least try to make sure that you follow up on it and that you make it better. Luckily, I would say that, but it's not a guarantee, so it's also a warning. Starting out with luckily is then a very bad signal, but using a design system with solid foundations helps you in getting up to speed. But as I said, it's not a guarantee because if you misuse the properties or the features of that design system, then you are perfectly capable of building something that's very inaccessible, even to the most normal, or normal is not the right word for this, but the most average human.

JQ: So it's both a tool as something that you need to still be considerate about. It still needs to be part of the development cycle anyway.

TD: Yeah, definitely. I like to compare security versus accessibility sometimes because security is normally seen as this Right, we need to do whatever we can to build it secure, which is of course very important as well. But leveling the tool, accessibility and security, is I think something that accessibility advocates should go for, at least try to up it a few levels. I think the European Accessibility Act will help with that, which is nice. You can also say, okay, we are not compliant right now if you don't do this, which to a lot of managers is quite convincing.

TD: But yeah, it's always nice to see and I think we will eventually get there once we get some more processes and maybe some extra tools also automation is on the rise as well in terms of accessibility. But also the processes need to be integrated, testing with end users, getting the knowledge and getting the trainings in for the organization, making them aware about building accessibly all helps. So thank you, Joran, for taking the time to record with us. I like the conversation very much. Where can people find you online?

JQ: Yeah, so as I mentioned, I'm not that active and maybe this will change over the year, I'm not sure. But you can find me on BlueSky, I think my handle is at johankwinterpunt.nl. Sorry, English. Which is also my website, which I haven't updated in quite some time. And by my first name and last name, it's a pretty unique combination. You can also find me on LinkedIn or anywhere where my presence on the internet is still visible. Yeah, so you can find me and I am always happy to talk with people. So if you want to share something with me or get something from me, feel free to ask and I might be happy to reply.

TD: All right, great. Thanks again. And to all the listeners, if you like what we do, please consider subscribing or liking or rating or leaving a comment. As always, always welcome. Getting some feedback, positive or not. We will read them. Yeah, again, thanks. Thanks, Joran. Yeah, you're welcome. Hopefully get you on another time as well because I think we can go on for some hours, hours extra as well.

JQ: Yeah, well, anything development related, it never ends. And it's always, there are so much movement, so many new developments, so many aspects as well. Yeah, I've made some notes before this podcast that I haven't reached half of them.

TD: Same, same, same indeed. All right. Thanks. See you. Yeah, you're welcome. Bye bye.

Takeaways

• Accessibility is a pressing matter that needs attention.
• Improving accessibility can lead to significant organizational success.
• Writing a book can be a rewarding experience, even if the content becomes outdated quickly.
• Design systems play a crucial role in ensuring accessibility in web applications.
• Legislation like the EAA can motivate organizations to prioritize accessibility.
• Balancing security and accessibility is a common challenge in development.
• User testing with individuals with disabilities provides valuable insights.
• Transitioning to management requires a shift in focus from coding to supporting teams.
• Staying updated with technology trends is essential for developers.
• Inclusivity should be a core principle in web development.