Stack Overflow's Accessibility Journey | #4 Giamir Buoncristiani

Transcript of the podcast

Video version of the podcast is available on YouTube.

Summary

In this episode, Tim Damen and Giamir Buoncristiani discuss the evolving landscape of digital accessibility, focusing on the initiatives taken by Stack Overflow in 2024. They explore the challenges of color contrast, the importance of automated accessibility testing, and the implications of the European Accessibility Act. Giamir shares insights on measuring accessibility, the role of accessibility champions within teams, and the significance of community involvement in reporting accessibility issues. The conversation highlights the proactive steps organizations can take to enhance accessibility and the importance of continuous improvement in this area.

"We got a lot of positive feedback from the community" - Giamir Buoncristiani

Disclaimer

In this episode APCA algorithm (Advanced Perceptual Contrast Algorithm) is discussed. The algorithm is currently being evaluated W3C. The information provided in this episode is based on the knowledge available at the time of recording. APCA is not part yet of any WCAG criteria, and it could be the case that it will not be included in the future.

Chapters

About Giamir Buoncristiani

Giamir serves as a Staff Engineer at Stack Overflow with expertise in UI Architecture and Design Systems. He heads various frontend projects across the organization. His recent accomplishments include improving accessibility across Stack Overflow's product suite and guiding the engineering teams toward contemporary UI development practices. He's dedicated to empowering teams to create exceptional user experiences.

Follow Giamir on:

• LinkedIn

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 today by Giamir Buoncristiani, Staff software engineer at Stack Overflow. Welcome.

GB: Hello, nice to be here. Thanks for having me.

TD: Hi, hello. Yeah, this is actually the second time for us meeting because the first time was in New York. Well, actually New Jersey, at the JS Nation conference over there. So that's nice. But now we meet online, that's also good.

GB: Yeah, it's nice to meet you again. I guess, you know, one thing that we have in common at that conference is I think that our thoughts were the true only thoughts around accessibility at that conference. So it was nice to catch up about accessibility there.

TD: Yeah, yeah, yeah. We met there and we spoke about, oh, we're going to talk about accessibility also. Oh, that's cool. That's nice. That's nice. Yeah. So we just entered 2025 as well, still in the first month. Yeah. Looking back at 2024, Are there some successes in terms of accessibility, organization-wide, but also personal you would like to mention?

GB: Yeah, absolutely. I mean, 2024 has been a pretty eventful year when it comes to accessibility for me, for my company, Stack Overflow. I work in the design system team of Stack Overflow where we're focusing on a variety of front-end initiatives. But last year, 2024, I feel like I could say that it was the year of accessibility. We had at least a full semester in our team where We think hard about how to improve the accessibility of our products. Yes, I think we, you know, between other things, like we released brand new color palettes for our design system, which is always not easy.

GB: As you can imagine, Stack Overflow is a pretty established website, and when it comes to do this sort of I guess migration or upgrades, it's always tough and it's a lot of planning, but I can say I'm pretty happy because the results now, it's a website overall that is much more accessible. A full year for us.

TD: So the changes they paid off. And did you guys change the color palette because the contrast was not high enough at first?

GB: Yes. So we knew since a while that we had some problem with our pre-existing color palette. We support also different modes like in Stack Overflow. Maybe people are not aware here, but if you actually sign up for Stack Overflow, then you can actually get dark mode or even high contrast mode. So our design system actually has to support all this variation and we We did have a few color contrast issues. Together with our design team, we revisited the palette to make the overall experience of our user a bit more accessible. Interestingly enough, I have an anecdote there as well.

GB: The current weaker color contrast algorithm, We struggle a little bit with that, even when doing the new color palette, because Stack Overflow has orange as its brand colors, and we couldn't move away from orange. But orange is, I guess, just notably a hard color to work with across accessibility. Because the WCAG algorithm often gives sort of false results like when you have for example black on orange often weaker past but like perceptually like it doesn't really be like that readable as, for example, white on a dark orange. And therefore, we also use, we decided for color contrast to move to a different color contrast algorithm that is called APCA in short, like it stands for It's always a mouthful, advanced perceptual contrast algorithm.

GB: It's a cutting edge algorithm that is currently being evaluated to land in WCAG 3.0, which is still not here. It will come eventually, I don't know when, probably in 2028 or something like that. We kind of decided, let's go there so that our orange could work and we didn't have to get rid of our brand orange.

TD: Ah, I see, I see. So, yeah, I also heard about this new algorithm for contrast in the upcoming version of WCAG. But you guys already went ahead and just implemented it. Yeah, sometimes I have the feeling when I do the contrast checking myself and give different results, of course, with different colors, but some colors, they pass. But still, to me, already, I have the feeling, oh man, I can't see them that well myself. So yeah, sometimes it's a little bit iffy, I would say, but I will look more into the new algorithm you mentioned. That's quite interesting.

TD: So you were saying that this solves your problem.

GB: Yes, that was one of the reason why we decided to, you know, it's never easy to adopt things that are a big cutting edge like because of course there is not All the tooling that you will get from more established algorithm, like the current weaker one. But for us and for our design team, we really couldn't get away from our orange. It's our brand color. So we decided how it is, the weaker, it's readable. The algorithms still fail. So we decided actually to explore this new perception algorithm. It worked quite well for us. The only thing, of course, is that there wasn't that much tooling out there, or there is still not that much tooling out there for testing, for example, for that algorithm.

GB: So we had actually to roll out some stuff ourselves to make sure that we we were able as a company to test with that new algorithm in a methodical way. That was also a nice occasion for us to contribute back to open source. We developed a few rules for the Axe engine that are leveraging this new algorithm. You can plug in in your test and instead of testing with the WCAG, algorithm like they would test with the app.

TD: So this is a plug-in for the app score.

GB: Yes, it's called app check. Like you can find it in NPM and also in Github. And yeah, it will essentially, you're using alongside AXA, right? Like it's another set of rule that you just add when you configure AXA in your test.

TD: Yeah. Oh, that's interesting.

GB: You guys have contributed to that new... So to the algorithm itself, no, it's a highlight, but to the tooling. The algorithm itself has been developed by actually, I hope I'm pronouncing the name correctly. I think they go on the internet as Mindex, M-Y-N-D-E-X, and I think they They're part of a research group at the university that have been studying color contrast for a while. There is a lot of theory behind that. the algorithm and it's pretty cool and I would like to see it in the next WCAG iteration. Of course, it's a breaking change so it can only get in WCAG 3.

TD: Yeah, I can imagine. But on the other note, really tough job to build in dark modes on an already established website like Stack Overflow. Must have been a big project for you guys.

GB: That's crazy. We had that mode since a while. Because of the previous palettes, in some places it wasn't really working right. Supporting that mode in general and also high contrast mode as well. It's not an easy feat. In our design system, CSS library, we have also introduced a set of Yeah, regression and accessibility tests that we automate, like with some tooling. So we have some tooling that, because there are so many permutations that our, you know, if you have a button component, you can have that button in the dark mode, you can have the button like in the high contrast mode, light, and in the high contrast mode, dark.

GB: And so you have all these different permutations that if you always have to test manually, take up a lot of your time. So we have established a set of regression tests. So where we have some algorithm that actually like automatically, automatically actually test for all these variants. Like, and yeah, but still, that's, that's better than not having everything like, but sometimes some bugs always manage like to sneak through, right, because there is so much to test. Like, like when we when we

TD: Yeah, can imagine. So you guys made sure to do these automated tests. So you have custom automated tests, but also, of course, you guys used OXCOR.

GB: Yes, so in our design system, right, which is, I guess it's the step is when we talk about accessibility, our design system, right, like it's, they are the building blocks, like the UI that we have across the cover for us. we want them to be as accessible and as solid as possible. So we have invested in a variety of tests for that system. And by the way, again, our design system is also open source. So if you're curious, you can just go to stackoverflow.design and you can even reach our GitHub repository to see maybe some of those tests in place.

GB: So we have a suite of regression tests for most of our components, where essentially we take a snapshot of component in different state and different variation. And then we have a suite of accessibility tests that run alongside it, which essentially they're doing a similar thing. They're rendering the component like in a specific state under a specific mode, and then they run a set of rules against it, like if something is not right. I mean, of course, they won't catch all the accessibility issues that we have in a component, but at least for stuff like Stuff that is a bit more automatizable like color contrast checking, they are very helpful.

TD: Yeah, I can imagine. Color contrast checks are really, really nice to automate, I would say. It's also quite tedious sometimes to test yourself. No, but that's great. And I never knew that this tech overflow design system was open source and available for you to see. I will check it out after the recording. Yeah, yeah. Well, good. And so for the upcoming year, 2025, do you see any trends? Of course, the European Accessibility Act is coming up. I think you guys prepared for that as well with this big project that you have been doing. And she also talked about during the conference.

TD: Let's get into that a little bit more maybe later. Yeah, what is this year going to look like?

GB: Yeah, so what I'm observing, at least from what I'm aware of, is that of course the The European Accessibility Act is the main topic, especially discussed across organizations. It has been a topic since 2019, really, because that's when actually the Directive Board was created in the first place. We had six years before now in June, we would get to a state where Okay, now, like all the government, all the member states in Europe, like they need to apply that directly and they need to start to enforcing it as well. So companies are starting to get, they need to prepare themselves.

GB: As always, as it's been also for GDPR here in Europe, there will be a period where Yeah, like, you know, it will be a gradual thing and we don't know yet like how, how things will be enforced as well. Like, because every member state have, you know, will have a slightly different law, slightly different fines. Um, and, um, yeah. And so it's gonna, it's gonna take a bit, but certainly like, uh, it's gonna be an year where a company I need to seriously adjust. like the website I like to be a standard because my understanding my like as far as my understanding goes like the EN301549 directive which is essentially the directive that is used like in European accessibility are state It essentially refers directly to Weka 2.1 AA compliance.

GB: So we will see a lot of companies trying to get to the standard. This is one of the things that we also done like Stack Overflow. Despite, honestly, Stack Overflow being in a situation, at least when we talk to our legal team, because the advice I have for people is just like, when it comes to this thing, just make sure to consult your legal team, like if your business is actually affected, et cetera. When we talk to our legal team, start going from being a question answer platform, they say that, look, by reading what the companies that would be affected by this European Accessibility Act doesn't look like we will be affected because there are e-commerce, there are a bunch of transports, but question and answer, community websites, stuff like that, it's not at least explicitly mentioned.

GB: It's just a question of time, right? So it's better come prepared and don't risk if you have the possibility and the actual financial mean and as an organization to prepare for weaker. So yeah, 2025, I guess, will be all about the European Accessibility Act. And going forward, I can see how the different governments are trying to actually extends also a little bit, like the guidelines that we have around accessibility, not just for the web, but also for other formats, like PDFs. We all know how the experience of getting some PDF document to fill out from a government entity or something like that, how bad the experience can be like even for people not with particular disability imagine like with people that you know maybe can not see that well like which could very well be asked in a few years from now right like so.

TD: No definitely definitely yeah so preparing for the European Accessibility Act, whether or not you guys will be affected. I think, of course, this is part of the power of the EU Accessibility Act, but also I think Just preparing to be better accessible is always the better thing to do. Either way, very nice that you guys took this journey. You also talked about this at the conference, right? Anything of the story still missing from the conference? Are there some notable things that you said at the conference? can talk about?

GB: Yeah, yeah, for sure. I mean, I can just give a brief overview of why we started on this journey in the first place. And this is because we knew since a while that we had pages across across our products, I like that we're not really accessible. And this was pointed out often like by also our community members, right? Because we have stackoverflow.com, of course, is our public Q&A website. And then we also have Stack Overflow for private teams, which is our SaaS product that many companies are using. We had reports coming in from community members, people like us that might participate to the regular StackOverflow.com Q&A, but also in our private instances of Stack Overflow from clients.

GB: We know we needed to do something, The way that accessibility was treated before we decided to actually embark in this initiative was very reactive. We would have a report and then people would scramble and say, okay, let's fix it, but without really put much strategic thinking on how do we make sure that we fit accessibility in a way that is sustainable for our organization, that scale, that can be a journey that continues over time and not just always reacts. a leadership like struggle as well a little bit like to invest on accessibility like because also it sometimes I like it just feel like this.

GB: fluffy cross-functional requirements that it's not measurable. And a lot of leadership want to see data, how things are progressing. And when they ask you how we do about accessibility, they want to be able to see some numbers. So actually, we focus on that. I guess my team, the design system team, show to leadership a way where we could start actually measure accessibility. And that was also the focus of my talk, by the way, at JS Nation. The talk was called Stop Guessing, Start Measuring, Quantifying Accessibility. And that helped us a lot to get leadership to invest, because we started actually to put in place some techniques.

GB: We just talk about testing now. create accessibility scores that can vary over time, that can be different from product to product, and show to leadership an indicator about How far are we as an organization or as a specific product from a specific target, accessibility target that we set for ourselves? Maybe I should say that if you don't have accessibility targets set for your organization, you should go off and make sure that you do that first. So you want to probably leverage weaker and say, our target is to get to weaker, in our case, weaker 2.2 AA compliance as much as possible and then we also have a high contrast mode that is all about those ones like we are aiming to AAA for a few things, I mean we would not hit AAA on everything.

GB: And then what this score does, what this score that we calculate does, essentially It's a score from 0 to 100, and if you have, I don't know, a 90 life for a product, it means that you have 10. If you get to 100, it means that you are sort of compliant, or let's say you are compliant But there can always be still some reports and bugs that we don't know about it, right? So it's just like as far as we know, as far as the different audit that we've done in an automated way, in a manual way, Like you are compliant, like, but there might still be something that maybe that you got to fix.

GB: Um, so that, that helped, that helped a lot, like in our, in our journey, like, like, so being able to quantify our stability. And after that, we were able to, uh, focus on shifting left, right? Like, because one thing is, okay, now we are able to measure, we have our targets and then And then the next step is, okay, we have to fix some stuff. And we did that actually in our design system because starting from a design, the design system is a great idea because it kind of trickle down to all the UIs. So being accessible there, I guess is step one.

GB: But then it's up to every single individual product team to make sure they understand accessibility. they actually talk about accessibility in their regular processes. So we thought that last step shifting left on accessibility. And for that, we also done a variety of things including creating, I think one of the biggest things that we've done is that we created this group of people that we call accessibility champions. So every team, every product team has one developer, like that is an accessibility champion like and meet. on a four nightly basis with the other accessibility champions in a forum where we talk about accessibility, what are the problems I can, what the teams they need to consider when they're building a staff life.

GB: So essentially being an advocate for accessibility within their team and making sure that in all the different steps of the development process, accessibility is brought up as a concern because in the end, You know, it's up to the product team then with the design system team in a central team, there is only this much that we can do, right? And then it's about enabling others, like to make sure to do, to do their work in an accessible way, right? Like, and this is what we've been trying to do with this effort or shifting left on accessibility.

TD: Getting these measures in place. You guys built this way of showing numbers to do management and tracking accessibility in that way. What are some of, so I'm guessing you guys use some ArcScore measurement style. Actually, the measurement style looked to me really like the Lighthouse score, which also is from zero to 100. Is it similar to what you guys have done, or did you also build in custom checks as well, custom measures?

GB: Yeah, so we are using to calculate the score of a product, the accessibility score of a product. We essentially do that in, it's a combination of things. So one part of the score is calculated in an automated fashion. So you're right, we're using Playwright and AxiCore running in a GitHub workflow. And actually, we are gathering accessibility course for a variety of our pages in our products. In terms of custom checks, we do have some sort of custom check because we're using, for example, a specific rule like APCA. We just talked about that a second ago.

GB: We do have some rules that are specific a little bit to us. Yeah. And then we actually upload. So these checks, they run on a daily basis, and they get uploaded in our observability platform. In our case, we use Datadog. And we call that automated score, actually. And then we have another score that is called manual score, because, of course, the automated score you know, you can catch, they say up to 57%, right, like in average of weaker violation, but then what about the other 50% or so, right, like that, you know, you need to do in a manner of fashion, like, and for that, like, we actually maintain a repository, actually we use Jira for this, like a central Jira board, accessibility board, like where we have a specific We have a specific actually like template, like how these reports should be.

GB: So we might have a client, for example, reporting us to us an issue. We might have community members, like so stackoverflow.com, right, like have also We call them a meta community, so I'm not sure if you've ever visited metados.covaflow.com. So essentially that is where you can talk about anything about the website and some people report bugs or accessibility issues. So we try to collect all of these reports into this central place. including also audits that sometimes we do internally or we ask a standard provider to do. So then we have essentially these VRA issues that are refined by the accessibility champion group that I just talked about, by people that understand accessibility a bit better, that are able also to assign You know, somebody say, okay, this is not accessible, but then we need to understand, okay, what rule is actually, what success criterion is violating of WCAG?

GB: So in this template, there is a few things to fill up, and then that will end in a to-do status. Like in this to-do status, actually, will help us to create this manual part of the accessibility score. Check the number of problems we have, of minor problems we have, according also with their severity. And then we have an automated score, a minor score, and the final score is essentially a combination of the two. So we do use an accessibility we had created an accessibility service, like so this is something custom we've done that pulls data from Datadog for the automated code, that pulls data from Jira, the Jira API, and it kind of creates like an accessibility dashboard that we decided as an organization internally, at the beginning we We thought it could be like an internal tool, but then we decided, okay, this is probably good also to share for accountability with our community and

GB: our clients. So we decided, why not? So if you go today at accessibility.stackoverflow.net, like you can see our dashboard that gets updated on a daily basis of how we fare on the different products that we have. We have Stackoverflow.com that is the Stackoverflow you all know, but also we have other products like the Stackoverflow for Teams, like our private Stackoverflow, etc. So yeah, that's how we create those scores. They have helped us out quite a bit in many conversations, not just with our leadership but also with our client community.

TD: Yeah, I can imagine. This is something also we were trying to work towards, like creating this accessibility dashboard with a variety of different data sources, one of them also being the external audits, like you said, but also the automated tests and also the ticketing in Azure DevOps or Jira, for example. These are all data sources that we are looking to combine in some way, some kind of dashboard as well. It's really nice to learn more about this, how you guys have solved it. Oh, that's very interesting. You were also saying about the accessibility champions just now.

TD: So every team has an accessibility champion that's also meeting regularly and discussing maybe progress or problems that's been running into. How does that work?

GB: Yeah, absolutely. So this was part of, I guess, the final part of our initiative, like we had a focus on shifting accessibility. So we've done a couple of things for that, creating these accessibility champions. group was one of those things. It's a group of people or advocates of accessibility that represent the team. We have four nightly sessions where we meet with this group. And we have a four-month for the session where we start from discussing, of course, action items that we might have had from the previous meetings. And then everybody can bring in, have the space to bring in something that maybe they're working on in their team about accessibility and they want to get clarification.

GB: So just yesterday we had one of those meetings. We have also one designer in the group of accessibility champions that represent our design team and they brought up a specific topic around progress bar. We are now redesigning a little bit of a progress bar and taking into consideration accessibility and it was an interesting conversation because there are a few new requirements, especially in WCAG 2.2 as well. We focus on making sure that things are visible. So when you have this I guess like you can call them like this progress bar where you have step one, step two, step three like sometimes they tend to be just you know the steps that you've done they are of a darker color and then the steps that you haven't done are of a lighter color so you have maybe three steps to do if you are at the first step you have the first one just like of a

GB: very dark color and the other one they are like very light and that can be an issue like for example for people that because there is not enough color contrast often, like with the things that are light, like they don't realize that actually there is an indication like about the number of steps. So there was a very interesting conversation that went on, right? Like, and we look, we often look also at what other companies are doing. Yesterday, we ended up looking at what Google with Material 3 has been doing, like for this specific problem, like it had an interesting, like a way to solve it where they added a little dot at the end of the things that are not completed.

GB: So instead of being fully, you know, over like color, they just have a little dot at the end. So that also people that have some visual impairment and they cannot see very well contrast, they can realize that there is some more steps are coming. So yeah, just to give you an example of the things that we might discuss, right, like into these meetings. And not just that, after that we have also 15 minutes or so to go to this Jira, actually to this Jira board that I was talking to you about, the Accessibility Central Jira board and talk about any updates of accessibility remediation that are ongoing, that might be that a team have picked up a specific accessibility remediation that regards their products, like we are tracking in the central post, so they might give update or other people might have questions.

GB: But also things that are new. Sometimes accessibility reports, they can come any time. You can have somebody reporting it in the middle of or the week and then we just create this placeholder in the trial. We have a triage section. And if there is stuff in the trial column, we take the time as a group to discuss these new bugs or issues that have been reported. We just accept all the reports, but sometimes they're actually non-issued. So there is also a little bit of triage to do that, like to understand is this an actual issue or maybe something else or something not related even to accessibility.

GB: So that's what we do as a group.

TD: Interesting. Very, very nice. quite similar to also what we are doing at the bank, meeting with a lot of different people from a lot of different teams, could also call them accessibility champions. Yeah. And this is, I think, a really nice and fun way also to collaborate with different teams on the same topic. And yeah, it's trying to solve the same problem as well. Yeah, it's really good. What I also found interesting to know is about the community that's also helping you. So the Stack Overflow community, there are a lot of users of Stack Overflow reporting things on the website, but also I can imagine, like you said, maybe accessibility vulnerabilities to you guys.

TD: And you guys seem to have integrated these reports by the community also really well into our remediation flow, so to say. Is that something? Yeah, how do you see this?

GB: Yeah, so I think this goes beyond, I suppose, accessibility per se. Stack Overflow having this large user base, we are lucky enough that we have a bunch of very passionate people about the website. We have all our moderators, so Stack Overflow. still today heavily rely on people, also reviewing questions. A lot of those people have this basis that we call meta, which is, if you actually go to meta.stackoverflow.com, you'd see it's essentially, it feels like another Stack Overflow, but in that, instead of talking about you know, programming questions and stuff like that. Like we talk about the website itself, right?

GB: Like, so we talk about stackover.com. So there are all sorts of discussions there, communications also to our community, like, but also that's also the way that people can report parts to us. I like so parts of any kind, right? Like, so that's why I say accessibility is part of that, like in the sense that it just does specific type of that people might report, or concern that people might have, like when they are browsing our website. And the way it works is that those websites are monitored by our our community management team, so we have a few people that are in charge of making sure that in general we see when something maybe is off.

GB: We also have some automation for that because the program has tags, so if somebody tags like a specific issue in Meta with accessibility, we will get in our internal accessibility Slack channel, something like that, like a notification saying, oh, okay, there's a new accessibility question post that you might want to check out. And that's how we essentially like get the input from the community when there is something around accessibility that doesn't work back into our central repository of issues. There is always something that we can do to improve, but this process for now works. Yeah, and it has proven itself beneficial when we fix.

GB: something around accessibility that community members have requested. We generally also get a lot of positive feedback, so it's also rewarding. I like to look at it.

TD: I can imagine. All of these things combined, I think you guys are on a very high maturity level in terms of accessibility. You're taking it really serious. I think the project And the monitoring, but also the color contrast changes all combined make it so. To me, it sounds like a really refined process and it's very interesting to get to know a little bit more about it from you directly. I'm going to thank you for that. Thanks for being on the show, being among the first of the podcast. Just to know if you would like to share it with listeners.

TD: Where can people find you online if they would like to follow you?

GB: Yeah. So, um, I, I'm not a super social media guy, like, like, but you can, you can certainly, I have a website, giamir.com. Uh, so my name.com. Uh, and my email is at giamir@giamir.com. Probably that's the best way that you can reach out to me. I'm also on X slide, like, but I'm not in LinkedIn, LinkedIn, of course. But, uh, I'm not super active on those, uh, on those platform. Yeah. To limit a little bit like my social media consumption, I like to remain sane.

TD: I can imagine in this changing world. You can get sucked into it really quickly as well. Now I'm going to thank you so much. Thanks for coming on the show. And to the listeners, if you like what we do, please consider subscribing or liking or rating, following us, following the podcast. And if you have a comment, please Don't hesitate to let us know any feedback you might have, good or bad, we will read them all and try to improve, of course. Thank you so much, Giamir, and I hope to get you on another time as well, because I think we can go on for some hours after this as well.

TD: Yeah, thanks for having me. Yeah, no worries. All right. See you later, man.

Takeaways

• 2024 was a pivotal year for accessibility at Stack Overflow.
• A new color palette was introduced to enhance accessibility.
• The team adopted a new perceptual contrast algorithm for better color contrast.
• Automated accessibility testing has been implemented to streamline processes.
• The European Accessibility Act is a major focus for 2025.
• Accessibility champions have been established in every product team.
• Community feedback plays a crucial role in improving accessibility.
• A central Jira board is used to track accessibility issues.
• An accessibility dashboard provides transparency and accountability.
• Shifting accessibility left in the development process is essential for sustainable practices.