 Hi, my name is Josh Minor, I'm the product manager for the iOS app for Wikipedia. And I'm going to be joined today by Volker Ekkel, who's one of our senior UX designers on the web, on the editing team. And we're going to talk about some issues with accessibility for Wikipedia and just kind of talk about some work that our teams are doing and that people are doing to help make Wikipedia more accessible to people with various kinds of disabilities. So I'm going to start by talking about Wikipedia for the visually impaired specifically. For those of you who aren't familiar with the term accessibility, it's pretty broad. It covers a lot of different kinds of physical and even mental disabilities. And obviously they have different needs and so focusing on them as individual subpopulations helps us just to kind of know what to do to make things better for them. So we're going to talk about for the visually impaired on iOS, but I'm just going to start with a little bit of the visually impaired dealing with Wikipedia in general. And the title of this is the part from our vision that probably most of you know, but which says that we're going to supply all of the world's knowledge to every single human being. And so that includes people with different physical and mental abilities. So who am I talking about in the case of the visually impaired? It's actually a really big population. It's very easy to kind of be like, Oh, I'm not blind. Maybe you know somebody or somebody who is, you know, fully blind. There's a huge range of visual acuity from, you know, full blindness all the way to have a little bit of a, you know, near astigmatism. The WHO, the UN agency estimates that there are nearly 300 million people around the world who are visually impaired. It's roughly 4% of human beings on the planet. It's actually dropped over the last few years as medical treatments for visual issues have gotten better, but it's still a very significant population. And if you think of that group of people as a language group, rather than as a subgroup of other languages, it's actually the fifth largest language in the world. So if we were thinking about in terms of our wikis, it would come right after English wiki in terms of the number of users that it could address and just before Arabic, which is interesting. And then even if you just talk about the US population of English speakers in the US, there are seven million visually impaired Americans and that's actually more than there are people who speak Lithuanian. So again, it's not an insignificant group of people that we're talking about here. And also one really big thing to think about is even if you are not a user of these technologies now, you may be in the future. So about a third of people after the age of 60 have a medical condition, which impairs their vision pretty significantly. And that's just on top of the normal vision loss you experience as you get older. So it's something that probably all of us will take advantage of at some point in our futures. But I think the one thing that I'm going to bring back to both on this slide and in a couple of times is that it's not really about the numbers. It's not about serving a certain number of millions of people or percentage of people. Partly it's about our vision and fulfilling our vision to bring knowledge to every single human being. But there's also a lot of ways that designing for people with disabilities and the visually impaired makes our designs better in general and makes our product thinking better in general. And that's kind of summed up there in the last line that the real impact of universal design is that you end up with products that are better for everyone by making sure that your products work for people with lots of different abilities. You just end up with a product that works better for everyone as a whole. So lots of good reasons. So how do the visually impaired use Wikipedia? I'm going to talk a little bit about mobile and then I'll probably hand over to Volker and maybe fill in a little bit about on the web. But there are basically two classes of ways that people get assistance. One is what are called assistive technologies. So you can think of this as the digital equivalent of a wheelchair or a cane. It's basically an additional piece of technology that is specialized for these people's needs to help them fill in an ability that they may not have themselves. So a couple of very classic examples or a couple of pretty common examples from the web or from mobile technologies are what are called screen readers. So this is a technology that basically reads parts of the screen and tells you what's on it so that you can basically understand what's on screen without having to actually see it. And then another type of technology is called a Braille display. And you can kind of think of this as a reverse keyboard. It's almost like if you had a keyboard, but instead of having set keys, basically the dots that encode Braille information move up and down as you roll down the screen. So basically you're reading the screen with your fingers and the keys that you're reading it from change dynamically as you move around on the screen. Josh, if you let me chime in here. Hello. I'm Volker Ekles. Josh already introduced me. The assistive technologies, and I really like the metaphor about the digital wheelchair or the cane. The assistive technologies are in some ways an interesting way to define how people interact with those software helpers because as a wise man for some days ago at an accessibility camp here in San Francisco said most of our interactions with computers are based on using assistive technology. So every technology that we are using is in some ways assistive technology and should be defined as helping humans to fulfill their goals and their tasks. Good point. Even a keyboard is an assistive technology for the right kind of people. And then the other thing that often helps people with accessibility is user preferences that are built into these systems to help specifically let the user modify the display or the UI to meet their needs. So a couple of classic examples that run both across the web and mobile platforms is color controls. So this is the ability to change or override colors on the web. Obviously that's been something that's been part of web browsers for a very long time. On iOS, another example is that there's a setting called high contrast colors, which basically just boosts all of the colors into a higher contrast range to make them easier to differentiate. And then another classic example is content size adjustment. So we're all pretty familiar with the plus and minus buttons on the web, which lets you scale and zoom items that's not really necessarily intended as an accessibility feature, but it's often a way for people to actually be able to parse out a website or read a website where the text is far too small for their visual acuity. And both mobile platforms also support a kind of system-wide text size setting to let you adjust the text size of apps and the UIs. Another little addition, when we're talking about improving our technology stack for certain groups, then we're excluding here people with cognitive disabilities. Those are things that the Wikipedia communities care about a lot as well. If you take, for example, simple English as one of the language Wikipedia's. Yeah, I should also just add to that that this is not something that Volker and I are coming up with today and being like, oh, suddenly this is important. This is something that communities have cared about for a long time. There's been a lot of volunteer efforts in this area from pretty much from the beginning of Wikipedia. So to actually experience what this is like, I would really, really recommend that you try it firsthand. So I'm the mobile apps guy, so I have directions for people who use mobile platforms up here. But there's also a link for screen readers for other browsers and other OSes. Most OSes now have a screen reader built in, Windows, Mac. There are some third party ones for Linux, which are linked, actually, in a different slide. But basically, almost all these systems work by you turning on a setting, you go in and then a voice reads to you what's on the screen. And so I'm going to turn it on so you guys can see what are here, excuse me, I should say, what it's like. You'll notice. Double tap to toggle setting. So that's the setting for turning it on and off, but I just tapped. Accessibility, back button. So basically what happens is the voice reads anything that you tap. Speaking rate, 66%. Adjustable. It's like going down with one finger to adjust the value. Tells you what the object is that you touched, what it does, and how you can interact with it. So it's a button or a toggle or something like that. And you'll notice one thing is the voice talks very fast. And we actually recently did an accessibility hackathon. And we had a iOS developer who we've been working with who's visually impaired or blind himself. He has the voice turned up to the maximum speed. It is pretty crazy to watch him navigate through the operating system, listening to a voice speaking at four times a normal speaking rate, five times a normal speaking rate, and being totally able to comprehend what it says and make use of it. So it's one of those things where it sounds a little bit hard for us because we're not used to it. But once you get used to it, it's something that is incredibly helpful and just becomes part of how you interact with software. And I have a little task for you because it's always fun to try to do these things. All our design research people know with a task in mind or with a story in mind. So if you try turning on a talk back on Android or voice over on iOS, try then going to navigate to the feature article of the day, either through the browser or through the app. You'll find it's a little bit of an adventure. And then last but not least, I just kind of wanted to return to the overarching point I made at the beginning, which is making interfaces accessible just makes design better for everyone. It means simpler designs. It means easier to understand designs. It also helps with testing a lot. Because you have to encode all of the information for user interface in a code layer and I'll talk more about that when I talk about specifics of what we're doing in the iOS app, it also means that testing systems can take advantage of those labels and that information and run automated tests or user interface tests in an automated way. So you kind of get this double bank for your buck where people who have visual impairments get a better interface and a better user experience and then internally you also get some benefit to just making something that is a little more testable in an automated way. And then it kind of reinforces a lot of best practices and software development. So be aware of your users and have empathy for them. I'll talk a little bit more about the iOS team and how we kind of stumbled. Stumbled is not the right word, but how we got into being really interested in this because we realized we didn't have very good empathy for these users. Listening to experts and end users. So accessibility is a pretty specialized area of technology. I am not an expert in it. I'm going to be real upfront about that. Volker knows way more about than I do, which is part of why I roped him in to helping me with this. But there are experts in this area and also end users in this area who will give you feedback and help you test. And then last but not least, it's continuous. So the title of this talk was Continuously Improving Wikipedia's Accessibility. And there was a reason for that, which is this is not something that you do once and then walk away and be like, okay, now it's forever accessible. Every new feature you add as the platforms get updated, as their new tech trends, you need to understand how that is going to affect people's access to that information if they can't see it. So just this again, kind of a nice way to reinforce best practices by serving a defined group of people. All right, I'm going to move on to talking about iOS specifically. So again, who we did this for? So just to by way of a little background, last winter, the iOS app was kind of redesigned from scratch. We went from a very browser-like presentation of a single article at a time to a more app-like presentation where we have feeds and collections of saved pages. And it was just kind of a major overhaul of the user interface of the app. And as part of that, the team identified accessibility as one of the things we wanted to ensure the new app was good at. Unfortunately, towards the end of that development cycle, we realized none of us knew what we were talking about. None of us was blind or visually impaired enough to actually need to rely on these technologies and as much as our good intentions where that doesn't actually help you solve the problem in a meaningful way. So Corey, who's one of our engineers, actually had a connection with a guy named Austin Serifin who's a website is linked there, who's a blind iOS developer and does consulting for apps to help make them more accessible in this way. And basically over the summer, he performed an audit of the app and gave us a lot more actionable feedback about how we could really support accessibility. And then one thing that is not meant to be a commercial for Apple, but just to state as a fact is that Apple has always prioritized accessibility features. Apple, to be real cynical about it, Apple sells widgets. And one of the things that they do is focus on anything that is both a combination of hardware and software because that's where they feel that their products shine and accessibility features are often that way where they involve the operating system, they involve the hardware of the device and they involve software. And so this is something that Apple has done since the 80s. All of their products have had screen readers in them and voices built in and I have a quote here from a guy who does not Austin but a different person who does consulting for app development and he says, it's the only mobile device I'll use and that's hard for me to say because I'm not really an Apple guy. And so it's one of the things where we feel like with our mission and with our sort of specialized audience within the iOS team, this is something that we could really focus on productively. So, all right. So I already mentioned asking the experts. So we've talked to Austin. We've also signed up a couple of blind beta testers so that when we push out betas, they can give us feedback. And then we also worked earlier this spring with a group called Ally who's done some other work on the Wikis. And so I also wanted to give them a shout out for helping us understand these issues better and filing some really detailed FAB tasks which were very helpful. One of the things that we've done and that definitely recommend is consulting guidelines. There's a lot of published guidelines for how to do these things. So the W3C has a guideline called the WCAG WCAG which is web, you probably know what it stands for. The web content accessibility guidelines. Yes. And that great sites, it gives you basically levels of how good your site is for different accessibility things. So you'll hear people say like it's AA accessible and that's based on the WCAG guidelines. And Volcker will probably talk a lot more about that. VK. Yeah, that. I'll probably talk a lot more about that. And then on the iOS side, Apple provides, you know, a section of their interface guidelines that describes how to be accessible. And they've also released a lot of training videos. One of which is linked at the end which kind of gives you an overview of how to make your app accessible and share accessibility. There's actually a lot of automated tools. So this is one thing that we've been discovering as we've been doing the sprint that these are extremely helpful. So just for finding basic errors, it's not gonna tell you whether your whole app is usable by someone who's blind but it will help you find, you know, little mistakes or things that we're missing. So on iOS, there's a tool called the accessibility inspector. There are many, many options on the web for putting a website into a tool and getting a grade or rating on how accessible it is. And then, you know, classic product development advice, dog food, so turn on voiceover and actually try to use it. Again, it's not, it doesn't come naturally if it's not something that you do all the time but it really can help just with finding basic problems or an understanding and getting that empathy that you need to do a good job. And then again, continuous process. One thing that we're trying to make sure that we are doing this sprint right now where we're focused on this and we're talking about it as a team and we had that hackathon day and we're doing this talk but we really wanna try to operationalize this going forward and just make accessibility a priority for us as a team and just raise the profile of accessibility issues. But I wanna make it clear that we're not trying to ghettoize this into like, okay, we're gonna be done in one week and accessibility will be perfect. It's an ongoing process. And as I talked about at the beginning, there's lots of other types of accessibility besides visual impairment that we can also focus on. So let's talk a little bit more about specifics in the app and what we've had to do to make it work. So we've had voiceover support from the beginning of the 5.0 series. You are always able to get the voiceover to read the article, for example, to do basic navigation, but it was pretty sloppy, to be honest. And that's because doing voiceover work requires some extra work from the developer. You can't just put a button on the screen, a standard component and say, okay, there's a button that does something, turns off on this popover. You actually have to tell the system where things are and luckily most of the time the system does know where things are cause it's laying them out. So that's usually covered. But you also have to say what something is. So something is a button, it's a slider. It has a range from one to 10. And then you also need to be really clear about what you call something. So a lot of systems will have default readers where they just take the label that's on the screen and just read that out loud. But if you heard a little bit when I did the demo, a good voiceover will actually not just tell you this is a slider for setting the accessibility speed. It'll say, move your finger to the left to decrease it, move your finger to the right. It tells you about how to engage with it and how to actually use it. So example I have here below that, the custom components is we have the W button in our app. And the W button serves two functions. When you're on the main home screen, the Explorer screen, it just scrolls the feet to the top. But when you're on any other like article screen, it's your home button, it returns you to that home screen. That's a little bit complicated for even for visually aware users to understand. But in our voiceover, when you touch the W button, it says W button, and that doesn't tell you anything. It's a W button. Great, what the heck is a W button? And so one thing that we're fixing in this version is to actually tell you what the W button does. So when you're on the feed, it'll tell you it's gonna take you to the top of the feed. And when you're somewhere else, it's gonna tell you it's gonna take you home to that Explorer screen. So it's not just about labeling it with what the caption of the button is, but actually informing the user about what the functionality of the button is and providing them the context they need to interact with it. And again, that kind of called out in the next one. If you've done UX design, a lot of it is about flows and context and hierarchies of information. So it's not just pieces floating independently, but how they relate to each other and how the user moves from one piece to the next. And voiceover has the same thing. You can't just take each label and make it independently. You have to think about how does someone navigate in the app and how, if they're having the screen read to them, how are they gonna navigate in the app? These are all been hard one lessons, by the way. I'm not, these are things we are discovering. So another capability of iOS that we are working on is dynamic text. So I mentioned user preferences for changing text size and that's what dynamic text does. So it basically lets users set a system-wide text size for UI elements. This is a really interesting thing because it seems really simple, right? Just change the size of the text by let the operating system adjust the labels on our buttons and make them bigger when they need to. But it's not quite, it's simple. The first thing that you need to do is define all of your texts and styles in terms of semantics. So you basically have to take all the things that say this is a 12-point Montserrat in bold and say now this is the title font and title means 12-point Montserrat in bold. And that way the system can understand what the text is for and not just what its properties are. And there were, I think we ended up with 60-something styles and I wanna give a big shout out to Rita Ho who was on the iOS team at the time and made a massive spreadsheet which took a lot of work to basically track all of our styles and define them in this semantic way. And then it also means from then on you have to define everything that you're designing in terms of ratios and semantics rather than points and pixels. So basically rather than saying I wanna use a 10-point font and there should be five points of spacing between it and the thing next to it, everything has to be defined in terms of this is a sub caption and then 10% of the space of the sub caption should be the padding to the right from the other element. So it actually makes app UI design a little bit more like using CSS EM styling or percent sizing that you're familiar with CSS layout. But that's a major piece of work for on the design side and on the technical side because we have to go through every screen in the app and redefine everything that way. And again it's a major time investment but it pays off not in just an accessibility but also helps with localization so that you can deal with fonts and character sets that are of varying sizes and need to be accommodated into the same UI. And also it means that going forward we have a little bit more design efficiency because rather than having to redesign or redefine excuse me, a style each time for each new screen or each new feature, this encourages reuse because you can say oh just use the title and the subtitle and we've already defined what that looks like. And that way when the user changes the size we know the titles all change in this way, the subtitles all change in this way. All right, that's a couple of highlights from what iOS is doing and we hope to have out in the app store three to four weeks depending on how testing goes. One thing though that has been a back and forth and that we've talked about in the team and there's actually a very long fab discussion about is how to read articles. And I think this really goes to the heart of taking the next step from basic accessibility support to actually providing a good user experience of the quality that we provide to the sighted users. And we're not always sure how to do that. And I think this is like a discussion that we're gonna have to have with Austin and other people who are interested in this. And I know it's a discussion that's been had on the web for a very long time. There's another fab ticket about this that's been around a long time on the web. And that's how do you read articles? So when you're reading a Wikipedia article out loud to someone, do you stop at every footnote and say square bracket one or footnote one, footnote two? Do you read every link? Do you read the URL of the link or just the description of the link? How interrupted do people want their experience to be? Would they rather you just read the whole paragraph and then at the end tell them there were five links in this paragraph. They need a bell or a signal that says, hey, there's a link here. And if you wanna stop me and hear the whole details, you can stop me. All of those things take development work, all those things are possible but what we wanna know is kind of what is the best experience? And I think there's no definition of that right now, at least as far as I can tell. If you want to participate, by the way, we have a next version that's called Lighthouse because we use code names for our versions and there's a fab link there and we have lots of open tickets, everything from small things to improve labels to major things to change components to use more standardized components. So if you are an iOS developer, I definitely encourage you to come participate. And we actually had I think six people at the Hackathon and we have eight or nine pull requests from them. So we've already gotten it's a pretty good volunteer participation but we welcome a lot more. And then I put some links down here and I think Volker's gonna have another slide with some resources too but a volunteer developer who you might have heard of because he's very active, the DJ wrote a nice sort of basic guide to accessibility for the developers of MediaWiki and just developers in general. The W3C guidelines which we talked about are there and then Apple has a very nice kind of introductory video about how to like understand whether your app is accessible and take some basic steps to make it more accessible. So and with that, I'm gonna turn it over to Volker. And I'll do questions at the end so if you just wanna hold until after each other. Josh. Okay, so no, I don't want to try the new present of you. I will start with a little, let's call it with a little rant because it sets the tone in a good way for the following slides. A lot of the work done for accessibility is about being empathetic and Josh mentioned that in one of his slides. Many newcomers to web development start designing their web pages in front of their high resolution monitors and gonna show it to their friends with their beautiful devices. And you don't grasp in the beginning how diverse the web is. Wikipedia has always been the opposite of such an idea. It has been very diverse from the beginning on and that is also why a lot of the Wikipedia communities have been calling out repeatedly for accessibility measurements because they were aware that it does not stop at your little screen in your living room. I want to, maybe I'm gonna stay here. I want to fastly skip about the briefcase we already did a lot of the terminology but I want to repeat the benefits. Benefits of web accessibility. It helps us all. If we are thinking about a high contrast for better reading experiences, if we are thinking about having semantics in HTML, I'm going to be a bit technical excuse that I'm gonna ask me later if you wanna go into the details. If we're gonna talk about semantics in HTML, this is something that helps you to gather, to gather traffic to your website because it helps machines, so-called robots to search through your site and index that site for the search engine which they are out here. I've already told you about the Wikipedia community activities that date back many, many years. As long as I can think as a Wikipedia contributor, I started in 2004 and there were already accessibility measurements that the community was going on, like readable colors and link signification. But, and this is a very important point as well. From the current technical perspective, we can do a lot but it's not feasible, technically feasible to create a website that caters for every type of person or every possible disability. This is out of our reach and we have to be aware of that. If we're talking about inclusive design, we have to be, we have to make choices and we have to be aware of what or who we are excluding in our work and how we address this exclusion as well. So basically in our current technology stack, giving those people possibilities to still read our, to still grasp our content but giving them probably a less advanced interface. A few more numbers. So I'm talking about the website of our work here. We are currently at 915 million unique devices for the top five language Wikipedia's per month on web. When we are very conservative, conservatively estimating the number of users affected by our measurements on accessibility, there's several hundred thousands. We are not, we don't have distinct numbers about that but it is, as I said, very conservative given the numbers from the World Health Organization and given the numbers of people with disabilities and statistics in the United States. I want to focus on three technical areas in my talk. I want to go a little bit beyond just visual impaired users. I want to bring you insights on our efforts for screen readers, which has been partly already mentioned. For keyboard users, usage of website does not stop with interacting with a mouse and for low vision audiences. Oh, thanks a lot. Screen readers. I want to start this off with a demo and show you how a screen reader interaction similar to the iPhone interaction of Josh works for voiceover user on Mac. Voiceover on Chrome, new line, selected. You are currently on a heading level one. So, I need two hands for that, an accessibility problem. From Wikipedia, the free encyclopedia jumped to you are currently on a tech internal link navigation. You are currently internal link search. You are currently on a link to click this link voiceover off. So, here you have already an example of something that is hidden to normal users. There's so-called shortcut links for screen reader users that give the ability to jump very quickly to a website to most use functions. We've been integrating this several years ago and it's still not a thing that every website out there uses, although it's self-explaning, usefulness and easiness to incorporate. That is great. I'm sorry, a short break here. I've made it. Okay, I hope you all took a deep breath. So, this is a slide that shows you what I've been focusing on. For the last couple of months, I've been working on OJSUI. OJSUI is our main user interface library. It is a toolkit that gives developers an easy way to create front-end web applications that operate consistent across, consistently across, multitude of browsers and devices with low-beginner hurdle. It is currently used, it just reached 4,000 commits on GitHub. As most of our software projects and open source projects, please be invited to contribute. And the things that I'm talking about are inaccessibility measurements, are not something that I've been coming up with on my own. It's an effort by thousands of people who are clearly aware of the importance of this topic. We've had over 50 contributors to the library on its own. It's currently used throughout our interfaces in visual editor, revision slider, beta features, and media wiki core forms. And as I said, screen readers are one of the technical areas that I want to present. OJSUI features the Web Accessibility Initiative ARIA, Semantical Extension, which gives web authors a possibility to expose certain elements just to assistive technologies, screen readers in particular, and let them easily interact with the user interface, widgets, like dropdowns, like buttons, like checkboxes, that all of you are seen every day in our interfaces. All of those four big parts of ARIA, W-A-I, ARIA, Semantic, sorry, LENPAC roles, ARIA attributes, live regions, and states and properties are currently already supported in our library. Can I go on here? The second part are keyboard users. I'm going to show a little demo here again. So the point for keyboard users is how do you interact with elements if you don't have a mouse, or if you have physical disabilities and don't let you use a mouse? And as you can see, I'm going to tap through the interface here. This is the demo page of OHSUI, and you see that you have a clear visual feedback where the focus of the elements are currently, and focus on which element the focus is currently, and you're gonna be able to not only focus it, I'm going to scroll a little further down here. But also interact with it, and go into the checkbox. So I'm tapping through with the space key, I'm going to uncheck it, and this is true for all the interfaces that use OHSUI. So this is a big part of our efforts to make that possible without developers to actively have to think about those things anymore. They just can use it out of the box, and they are there. I'm gonna go back. And the last point are low vision audiences. When I came to the, when I started working here, we've been having a color palette that worked very well for a certain type of widget, and one of the main efforts in my work since I started was to bring together designers and UX engineers, and talk about how we can leverage this color palette, that is a basic necessity in our products for increasing the color contrast, and therefore addressing our users like in low vision audience. And this is our current output. I'm very happy that we've come so far. We at the Wikimedia Foundation not only feature this color palette as a basic tool set, we are also including in our, for our community, the compliance levels, the WCAG 2.0 compliance levels into the color palette. So all of those colors here are level AA compliant. And again, a big shout out to my colleagues and as designers on the design front and UX engineers, because this color palette is not only used in OHS UI, as you will see, we have been bringing this color palette to different products already, in part the apps that have been mentioned before, and also our web products. It's an ongoing effort, but this is a nice step that we've already accomplished in big parts. And as last point, a little outlook, we have been communicating in this task of defining the new colors of the color palette with community members that was very successful. We are on the, sorry, I'm missing a word now. We are trying to overhaul and strengthen the online documentation. Josh gave a shout out to the DJ who came up with Developer Guideline for Accessibility. This has been around for, I would say, three or four years now at least. And as Josh also said, the technological advancement doesn't stop, so we are going to focus in the next couple of weeks of condensing and strengthening those articles out there to make it easier for people who want to write articles, who want to include tables in their articles, who want to make pictures with descriptions for screen readers to be clear what are the best practices to address low vision audiences and screen reader users. Another point that makes me very excited, in contrast to the iOS app, we've been talking about integrating automated accessibility testing in our continuous integration environment on the web products as well. But this is a bigger effort, or I'm not saying a bigger, I don't know how bigger effort is, but it is quite a huge effort on the web products to include that, which would give, what is the advancement, what is the advantage of this? This would give a direct feedback to developers writing code, showing them very basic errors and very basic feedback so that before the product gets even deployed, accessibility errors are hindered to become part of our products. And as the last point, we definitely want to fix all our tasks tagged with accessibility. I wouldn't say it's undoable, it's a few, but I think we're... There's a few. But I think we are aware of that and we are clearly optimistic about the future of our web products and also our app products. So thank you for your, for your, wait, this is the wrong, see? Double thank yous. Yes, double thank you. Thank you for the audience to come here and to listen to us and I hope you are with us on that fight for making our products easier to access for everyone. Thank you everybody. So I think we're technically at time or slightly over time, but if anyone had any burning questions. Nope, all right, cool. Thank you. Appreciate it. Thank you.