 Hello, everyone. I'm super excited to be here today. My name is Emma. I'm a software engineer at Spotify. And yeah, I've been working on Backstage over the last five years on different parts. And I'm super happy to be here today to talk about accessibility. So let's take a few steps back first. We're all in here on a mission to make Backstage the industry-leading developer portal, right? Because we love and care about happy developers. And I believe if we want to get there, we need to build Backstage with an inclusive mindset. And what do I mean by that? Well, I think we need to build and test Backstage based on input and needs from a wide set of users. By doing so, we will improve accessibility and thereby increase the number of happy developers as well. So yeah, last year we've paired up with our amazing accessibility team at Spotify on a mission to make Backstage a little bit more useful for everyone. So I'm here today to talk about the audit process that we went through, but also present a couple of actions that you can take already today to improve accessibility of your Backstage plugins. So this has been a three-step process for us. We realized pretty quickly as we started off this work that it would be impossible for us to audit all the plugins out there. So we decided to scope the work to Backstage Core Futures as well as the commercial plugins we have. The second step we wanted to take was to run the automated audits and third step, the manual audits, which is still in progress at the moment. But why do we want to include both of them, maybe you ask? And the reason for that is while automated audits is a great start for you to kind of start, identify issues quickly, but it only captures a low amount of them. So it's super important to let users actually walk through the product so that you can catch more issues to solve. As I mentioned, we're still in progress with the manual ones. So I'll focus in on the automated audits today. So yeah, we used Lighthouse DevTools to conduct our automated audits. And on the screen here, you can see that I've navigated to Backstage Entity Page, open up the DevTools, as well as navigate it to Lighthouse. Lighthouse is a tool to improve general web quality of web pages, but we use it specifically for accessibility. And by using Lighthouse, we were able to identify 106 accessibility issues across these plugins, where today we have resolved around 76% of them. And yeah, as you can see, you are able to configure Lighthouse based on which mode you want to use, which device you want to run on, and which categories. And then you click on Analyze Page Load, and it will generate a report for you. And what's really good with this was not just that it identified issues for us, but it also linked out to additional information of how to resolve the issue and also the user impact it had. So among these 106 issues that we identified, a couple of the common issues that I wanted to lift up here today was, for example, not having enough color contrast, which means that elements blend in together, and it's super difficult for people, for example, with low vision or being colorblind, to actually distinguish the elements from each other. Two other common issues that we capture were that the HTML wasn't structured properly, which means that when you're using a screen reader, it doesn't get announced to you correctly, which means that you can't navigate through the page. We also, of course, wanted to make sure that the issues that we fixed didn't return into the product. So what we did was that we added CI checks to the backstage open source repo to make sure that we were running these checks on all the plugins that we configured to run on. We were using Lighthouse there as well, but this also means that we do not introduce new issues, but also the issues that we have fixed doesn't return. Since we added the CI checks on the open source main repo, we have also seen checks being added on the microsite, which is amazing, and this is all because of this amazing community. OK, three ways you can do to improve accessibility on your backstage plugins. First thing, you can obviously as well run Lighthouse DevTools or Lighthouse CLI on your plugin as you develop them, which means that you will catch these issues early on. Second thing that you can do is I mentioned that we already configured backstage main repo to have to run these checks in CI. So you can add your plugins if it lives inside the main repo to this configuration, so it will automatically run on your plugins as well. But if your plugins live outside the main repository, you can use the CI checks we have put together with GitHub Actions and move them over to your repo. And if you're not using GitHub Actions as you see a provider, you can also, of course, look at the official Lighthouse documentation to see which other ones they have supported. We have more documentation around this over at backstage.io slash docs slash accessibility if you want to read more. But maybe you sit here and think, this is all in the development phase. Why do we need to go all the way there to actually start identifacious? And if you were thinking that, I'm very happy, because I also wanted to send you off with some from my perspective things that we can do already earlier in the process. So from a product research perspective, really make sure that we include this as part of the requirements that we create, because it all starts there, right? And as you are doing a user testing, make sure to include a diverse set of users. But also, put yourself in the shoes of your users. You can also use assistive technology. There is this keyboard testing template that I wanted to share with you, which you can use to actually walk through the product with just keyboard. And on the design phase, I wanted to send this with you, because I got introduced to this Figma annotation kit a while back that lets you annotate your designs with accessibility labels so that when you hand it over to engineering, it's easier for them to pick it up. So for example, should this be a decorative image or an informative image? So that means it can easier decide which alternative text we should use, for example. So there has been a lot of teams involved in all of this work. And the backstage community have picked up issues and improved this as well. So I just wanted to send a huge thank you to everyone who have worked on this. And yeah, thanks for listening into this talk today. And if you have any questions, I'm happy to chat with you throughout the day as well. So thank you so much. Thank you, Emma. Any questions for Emma? OK, there you go. One more. We have a break after this till 11.05. Thank you for that presentation. I have two short questions. First, have you found any ways to improve the backstage default themes while you're through your investigations? And second, do you think it would be worthwhile offering more themes to users by default to adjust for personal preferences? Yeah, great question. So one of the issues that I presented here around the color contrast, so that was actually one of the issues that we found were around the primary color that we used for the theme. So that was an update that we did across the themes, which applied to many plugins, right? So that's one thing around offering different types of themes. I think at least one of the issues that we have found is on a third-party library that we use for code snippets, which comes with a theme that is not accessibility friendly. So that's probably something that we'll look in together if we can create a custom theme for that one to bring into the project. Thank you.