 Good afternoon, this is Hadi Rangi, a member of IT accessibility team and I am delighted for this opportunity to have the time to talk with you about testing with a screen reader. It is something that I am being asked frequently, how can I test with a screen reader? Can we rely on a screen reader testing or not? That's why we put that as a part of the twice in a year and then we discuss that and share with you the updates. So what we will be talking today, first we discuss a little bit the difference between technical accessibility and then functional accessibility and then how and then what we should test when it is about accessibility, testing and evaluation and talk a little bit about what the screen reader are available and then share with you how they work and then finally we will answer that if you can use the screen reader and followed by a real demo of some testing. So I try to shorten these preamble stuff and get a real accessibility testing demo because I think it is the most interesting part of the presentation. So when we talk about the technical accessibility or what is technical accessibility? In technical accessibility we focus on specific element if they meet the coding practice and then guidelines. For example, check a specific button if they can be operated via mouse, keyboard, assistive technology and other means and then we check the code against the standard and then we said this specific button or this specific element it meets a standard and it is technically accessible whereas in functional accessibility we focus mostly on overall task and then we really come up with a functional task for a website or for a application and based on the functional task we can see that if a user can complete a task from A to Z. I have a lot of examples that we can say that. For example, when you are in a web environment for like Gmail, when you are sending a lot of people are using, we write down the list of the possible tasks in that space and one of them could be composing an email. Composing an email consists of many steps from finding or locating the compose button, clicking on it and then going to the next page and then filling out the forms like two fields, cc field, subject line and then body of the page and then running the spell check and then finally sending the application and then getting the confirmation that the message has been successfully sent. So all these stuff are when we consider for functional accessibility we have to consider all these steps and then and during that process every step must be accessible. They are like a chain, they are connected to each other and then only a complete chain provides a fully functional accessibility. In summary or putting them together for all those steps that I mentioned earlier, the user has to be able to access each element in that lengthy process. It would mean that those elements must be technically accessible so user can perform the task. In summary, technical accessibility is required and then but it's not sufficient. But both aspects are really necessary to make sure that the task is accessible fully. So technical accessibility is something that we focus on the element itself and functional accessibility on the entire task. Now, with this aspect, when you are going to do some testing, there is something that you will have to be ready. I mean, I'm not saying that it would require a good deep knowledge of HTML and then the web how it works but some familiarity with the web can be extremely helpful. For technical accessibility, which I mentioned that we check every element by itself, there are a lot of tools that we can use and then obtain the information. However, there is not enough, I mean, accessibility tools. This is something that we have been discussing for a long time. They can catch in the past I said that maybe up to 30% of the issues, they could catch it. Maybe using the AI artificial intelligent technique, maybe it can catch a little more but definitely it does not substitute for the manual checking. We still need to check for manual testing. And a screen reader can help you with partial testing. I will tell you when we can use it but it is not something that we should use screen reader for testing. Maybe I should not have said that right now but you got my answer. And then when you are doing the testing, remember, we are not checking just for the technical accessibility. We want also check for functional accessibility. We want to make sure that user can perform from all those tasks defined in a task from A to Z effectively and reliably. So when we are testing that, all users should have almost equal experience. If a task test takes five minutes for you to do that, for Hadi as a blind person, it should not take 100 minutes. I can understand some overhead but not at that level. So unfortunately, we see that many developers that they focus solely on technical accessibility and they do not consider how difficult it is to complete the task as a non-mouse user. And then when you are doing the testing, make sure that you do not really follow the tab, get lost in the task, focus on the big item issues. So what do we test? Okay. Before we start that, I should say that we should not touch screen reader testing before completing the keyboard testing. It is so essential and then many screen reader functionality depends very much on keyboard accessibility. By testing keyboard accessibility, then I think everybody in this room can do that. You eliminate a lot of issues. If you see that, for example, something is not working with keyboard, then you can with high probability, you can say that that task is not accessible for a screen reader either. When we start with the testing, as I said, we do that first, the keyboard testing. So keyboard consistency is one of the first items we see that. So consistency, I'm sorry, can consistently add application. So we check for the visual consistency. I mean, when we go from one page or from sub-page to another sub-page, they give you the feeling, give the identity here you are on the same domain. And then the way how they implement those elements. I mean, the typical example that I usually use is this. I see that, you know, from one form in the same domain, when they are asking for the gender information, they use, for example, radio group. That's not good. For example, gender means a male, female, or don't want to disclose something like that. You go to the same domain in different form and you see that they are using a combo box. The reason for the functional consistency is this, that people have to spend time to familiarize themselves with the page. For sighted user, this happens on the fly. But for screen reader user, we see only one element at the time. It takes time. So we want to make sure that once you use familiarized with certain elements, implementation of the page, we remain consistent throughout the domain. And then we don't confuse them by different implementation. Proper user elements. So a lot for a lot of developers, link and buttons are the same, but they are not. They are designed for different things. The button should trigger a function and then links, it should take you to a different page. So by mixing them up, you confuse user with their expectation. For example, when I'm clicking on a link, I'm expecting that I am redirected to a different page. But when something nothing happens and that link is just triggering a function in the same page, then I am confused. So you see that this is very easy to confuse us. Keyboard operability. So when you are doing the keyboard testing, that I would love that everybody develops at the scale. It is so simple. You just use your keyboard. You do not need deep knowledge of keyboard testing. You just need to know that you see the focus. At any stage, you, as a tester-cited user, should be able to see that the focus indicator. You should not even always blame your eyes. Oh, maybe my eye is getting weaker or I need a new glasses or I didn't sleep well or my screen. I need a bigger screen. Yeah, they might be a problem, but the real problem is the focus indicator is not there. You should be able to see the focus indicator at any stage. So you define the task and then what I would like to mention that. You tap through the page. You know, tap key is one of the key element that takes you from one element to another element. And then you should be able to see that. You should press the enter key to trigger that link or function. And then go through all those interactions as needed. If you have, for example, when you are on the radio group, you should use your arrow keys. If you go through a combo box, you have to use arrow up and down to open the combo box and go through the option and press enter to select it. And this is really so simple. And then the spacebar usually for check or unchecking the checkbox. I don't remember more stuff that you need just to do that. But while you are doing, you have to be able to complete the task, complete the task from A to Z. Do not cheat and then use your mouse and then, you know, move the focus to where you want. Because navigation and interaction, this is something that you do with both with the keyboard. If you are, you have to travel 60 times from A to B to perform the next action. Then you can ask your question if the task is functionally accessible. Yeah, technically, yeah, you might be able to do it. But if you have 15 steps to complete the task and every time you have to press so many number of tab key to go from A from one element to another element, then you can question the functional accessibility of the application. And as you tap through that, you always have to pay attention to the logical order. So if you tap through the application, and if you see the tab, the focus indicator does not match your expectation, that means that is broken. That is broken and you have to consider as a keyboard accessibility issues. And then go on to get confused with the shortcut keys. A lot of our developers, including our Microsoft and many, many other applications, they rely on the shortcut keys. Shortcut keys are can be extremely helpful, but they are not primary element of accessibility. Shortcut key can be good and useful, as long as they are meaningful, and they are maybe a handful of them, and they are consistent. But when you go through the shortcut key of some of these applications, you will see I'm not exaggerating over 100 of shortcut keys in a different with different modifier keys. Sometimes Alt Shift, Alt, Alt Windows key, Alt Control, Alt Control Shift. And again, it has no way that you can associate with that function. So there is a limit how many you can do it, and if they are consistent or not. And then again, do not buy, do not fall into that shortcut keys are not keyboard solution. Arial landmark, it is one of the most important thing that for a screen reader user, there are a lot of tools that we, these accessibility tools, that they can show you what landmark, how the landmark are defined or designed. Landmark or regions are logical, it is a way to deliver to convey the logical component of the page. You know, when you are taking to a random page immediately, you cannot identify that there is a banner on the top, there is a navigation, on the left, and there is a main area or there's a search and footer section. You as a sighted person can immediately see that. But for a screen reader user who see only one element at the time, this outline, they don't have access to this visual clue. Arial region, Arial landmark, is the solution for that. Practically, I mean, when they have container element on the page, and then you see something as a, like it looks like a banner section, that behind that banner, behind that box, it is a kind of, we call that an element, the IV element. And then Arial regions is a way to give a semantical meaning to that container. So when Hadi as a screen reader user comes here, he can see, oh, these are the major component. There is a box labeled as banner, there is another box labeled as navigation, another box like a main, and then, and so on. There are seven predefined regions in the spec, and then that is something that we use to understand the overall outline of the picture, of the page. So those are stuff that you see immediately, where is what, and what are the major component. We have to rely on Arial regions to understand the component of the page. So we will show, I will show all of them in a demo. So when we talk about that, we want to make sure that the integrity is important. Once you start using these regions, we want that you are consistent from one page to another page. And there is no content outside these regions. So because once you provide this box model or whatever, we got the regions, we are looking for the content inside the region, these boxes. But if you put in a content outside this stuff, it would be a little difficult to discover them. And of course, you know, if you have, you can name these regions, and then it is important that you use meaningful labels for these regions so a user can identify with them. Heading, you heard, I'm pretty sure many of you heard that before, headings are a means to structure the content. The difference between heading and then the earlier item regions are regions provide, gives you information about the structure of the application, about the website of the framework itself, and headings are reserved to provide information or provide the structure about the content. So in the heading, we have in HTML, we have six level of heading, heading one through six. And then the recommendation is that we use one heading one per page, which come with the main information about the page. And then anything underneath should be heading two and beyond up to six. It is important that we use this heading in a hierarchical way, and it should be meaningful, and it should be complete. What does it mean to complete? So first I go with the previous item where I said that, you know, meaningful, or hierarchical, we cannot have a heading three without prior heading two. It is like a book chapter. You know, when you go to see the book on the table of content, you have a chapter one, chapter 1.1, chapter 1.1, 1.1, and so on. And you see that each, when you go farther down, you build that relationship, you know, that chapter 1.1.1, it is a child of the parent, you know, 1.1, and 1.1 is the chapter of previous. So you build this hierarchy using the heading, heading one, two, three, four, five, and six. And when you are creating this heading, meaning the headings, you know, you want to make sure that they are meaningful. If you just use a few keywords, you know, that might not make sense to your audience, you know, then you probably want to rephrase it. Completeness, it means you cannot just say that, hey, I took care of the heading by putting a few headings on your page. Headings should provide a good outline of the entire page. So by providing heading only for a selected section, yes, you did a good job, but it is not complete. You have to provide the headings for the entire document, entire page. Next, grouping of elements. What does it mean? You know, visually, I mean, I'm talking about the ordered and unordered or definition list. So grouping elements is really nice. If you did that correctly, screen reader user can see that they are approaching a list. Screen reader reads the information from browser, and they know that, you know, that there is a list here. So before we navigate into the list, we see that, oh, I am entering a list of five items. And then I can go through it. If you do not, if you just do not use the proper coding and use, and try to mimic the list, as much as, you know, your fake list looks like a real list, it does not provide the necessary information. So in order to benefit from this list information, then you have to provide the right coding. So for both ordered and unordered list, so we need a proper coding. For the graphics, I think it's a, you know, a stereo, you know, this is something that everybody has heard about it. You know, we said that we need the meaningful text information for the graphics. If some graphics, if you consider that you think it is just a stylistic effect, there are ways to mark them as a decorative. And then once you say that it is decorative, you know, then screen reader do not even render that. So we are not overwhelmed with these noises. But when you see a graphic is informational, we need to provide all text. And then I have to, I've been pushing for that or promoting people, you know, to have those, the real author or authors to provide all text. If you are a content creator and somebody hands you information, it has graphics, I think it should not be the job of the content creator to provide the all text. The author should provide that. Because he or she is the only person who knows that what they wanted to convey with that graphic. It doesn't mean that we should not try it, but I think the best person is that person, is the author. With the phone controls, you know, we see that there is, I don't see many PhDs these days with our phone controls. There are some, a lot of them on the web. And then the fact that we see phone controls, oh, by the way, let me say the phone controls, we are referring to text boxes or input field or text area. We are talking about radio group, check boxes, buttons, or toggled buttons. But did I miss anything? And then, you know, more, I think that I covered most of them, the basic them. So when we are interacting with the form element, it is important that we provide the proper label with the form control. Otherwise, we would not, we wouldn't know that what we are doing. If you have, for example, two text fields, you know, one of them is, for example, first name with this last name. If I tap to those area, it just would tell me it is a text box. But if do we do not have, but if we provide the proper label for each text boxes, and then when I get to either of those boxes, it tells me first name, or last name, or whatever the field it is. So form elements or form labeling is really a key accessibility factor or problem from whatever perspective. We see that and it is a failure, a total failure, if a form control doesn't have the proper label. And tools, accessibility testing tools or inspector element, they provide all this information. This is not something that you need to know anything about the screen reader to test it. And then part of the form controller, we usually talk about the error handling and how you convey or how you convey an error, how you help users to recover from an error. And then, of course, a lot of dynamic widgets. If you are, I think, I'm pretty sure we all are using very difficult, I mean, very complex application. I mean, just consider it a workday or teams. Each element is not just a simple element. This is a combination of the multiple elements. Hi, Hadi. We're at the 130 mark. Thank you. Thank you. So it is so important that we test the form elements. And then, of course, then we get to the dynamic widget, that a lot of things are happening on the page dynamically and how we convey these changes to users, including users with screen reader user. So I think I need to go faster. So when we get to screen reader, I mean, in the Windows world, we have NVDA, JAWS, and Narrator. Narrator is built in screen reader from Windows. For many, many years, they were not reliable stuff. But recently, they have done in the past years, Microsoft spend a lot of resources on that, made it better. JAWS is one of those screen reader that is used in North America, I think, more than any other screen reader. And NVDA is a free one. And then JAWS was for many years, is mostly a dominant one, but NVDA is catching up with them. In Mac, we have voice over. And then in Android, we have talk back. And then iOS is also voice over, functionally very similar. What you see on the screen is the 2021 screen reader user, screen reader program usage. They haven't updated that result, but as I said, for many years JAWS was the dominant one, but NVDA is catching up with it. So one more thing before I go to the next stage is I wanted to emphasize that screen reader is made for blind user. So the manufacturer are trying to help blind user, not you as a poor testing. And they have hundreds of functions that helps blind user to obtain the information. And then, so some of them are algorithm that helps them, helps screen reader user to to identify some of the information that it is not apparent to user. For example, if the form label is missing, JAWS is trying to guess the label for that. But what JAWS is doing, it doesn't mean that other screen reader are following the same pattern. So that's why I always say that do not rely on screen reader user, screen reader testing, because you get a lot of false positive results. You see here the screen reader reads the label, but indeed what you hear is just that the fact is that JAWS is guessing that, not programmatically is in the application. So screen reader are going to have two major modes, browse mode and then interaction mode and browse mode. We try to understand the content, the page by itself. Everything we said, the way that we communicate is everything from left to right, top to bottom is linearized. We can see the page for every element of the visible element on the page, including those areas is just text. So again, we see these elements, these text information, graphic labels and so on, but we do not know their positions. We know just that they exist, but we do not know in what order they appear and then where they are located geographically on the screen. And then this is what we use for discovering of the page and then understanding where is what. But when we get to the interaction, we have to switch the application to a different mode. So in that mode, practically we tell the screen reader here, do not capture anything and then anything that we type is passed to the application. In the browse mode, anything that we type is considered, is intercepted by screen reader as a command. For example, in a web environment, if I type letter E, screen reader catches that and said, oh, he wants to go to the next edit box. If I type, for example, X, oh, he is looking for the next checkbox. It helps me to navigate in the page, but if I want to interact with that checkbox, then I have to leave that mode and then the screen reader do not intercept anything. And then everything that I type is passed to the application like you are using just keyboard. So the final answer is that yes, you can use the screen reader for selected testing. If you know some of this limitation, and then please do not follow and do that trap, there is something like JAWS accessibility, VDA accessibility, we do not have such term. So either a page is accessible or again, we tested not against JAWS, we tested against the standard, the 2.2 guidelines. Okay, then again, emphasize that for a lot of stuff, you have to do that manual testing. And then if you are not an expert, screen reader user, please do not use that unless you really know what you are doing. So this slide will be shared with you. There are some basic commands for the screen reader. If you want to play with it, we have listed, I think, NVDA, JAWS, and then voiceover, I guess. We will share with you, we don't have to go through all of them, but you will have them and then you can see a summary of that. So I have preloaded these pages that you can go to demo section. Okay. Now I am wondering how I should do that. So you can hear my JAWS. So let me disconnect my headset. I am slowing down, turning up. I hope everybody has coffee and on the side so you don't fall asleep. So and then I am going to show some of those features that I discussed earlier in action. We have developed this site just to demo accessibility features. We have an accessible version of this page as well as a very inaccessible version update. This page that I am on is accessible version. So I am going to show some of those features so you can see how they help me. I told you, when we get to a page, the first thing that everyone else gets to a page is you want to know what are the big information of the page, what are the big major component of the page. And then remember the regions that I told you are your regions or landmark. And the screen reader gives me an option, a function to view that. You as a keyboard user, you do not need my tool. You can go to these accessibility testing tools that I am sharing with the slides at the end of this presentation. You can download them and then use them. We will be glad to show you some of those basic functions and then help you to get started. But again, you do not need a screen reader to test that. So I am going to show the screen reader. I am asking Jaws to show me the RER regions. I hope the speed is not too fast. Is it too fast or too slow? Does it mean everything? Okay. Yeah, sounds good here. Thank you. I appreciate that. I am closing the sub regions. So my screen reader is telling me that the page consists of four regions, a region called banner, a main menu navigation, the term that you see to the end of that, it tells me the type of the regions. As I told you, we have seven predefined regions. I did not mention them. One of them is banner. Another one is navigation. Then this is a main. Then we have complementary. We have forms. We have search. We have footer and so on. And then it tells me, you have a banner. I have a main menu navigation region. And the main, which is the main region. And it says the closed. It means it has sub region that I will expose it in a second. This is a complementary region. And the content information I think is one of the ugliest word for footer. But this is something that they came up with. When I go to region, it tells me it contains other sub regions. And it has a slide show. And a video. And then if I want to navigate to that place, I mean, first, remember, it gives me an immediate outline of my application and the major component in it. So it helps me not only to understand the regions. It helps me also to navigate to that. So using this function of the screen reader, when I am, for example, on a slide, as I slide to a cursor, I can press enter and my screen reader focus is right there. So, and then I can read down from this, from this place. I'm sorry. That, that is the marketing, the marketer, but I think one more ring and then then it would over. No, they are persistent. Okay, done. And then the next things that we, as a screen reader would love, we utilize it after understanding the regions is the content. I mean, we want to see the content. And remember many headings, we said that this is the tool that we use for to understand the content. So a screen reader gives me a function, you know, to release the headings. So what we have here is a list of the heading and the numbers that you see on the right, it shows the level of that. For example, the first one that I'm on is the heading one. And again, we always start with heading one, which conveys the main title or main heading of the page. And welcome is a heading two. This is very logical. This is another one heading two. Another major section of the same level heading two. Another heading two. So, but when I get to the heading three, I know that based on this structure, this heading, this or subsection is a child of this guy. So by providing the heading structure, you give me all the, not only what is on the page, you help me to understand the relationship of the major and subsection. And besides that, I can press enter and navigate to that section. So it is like you looking at the book or looking at the article or what the page and then you just see this heading and subheading and the scheme through it. And then, you know, then you move your focus to that section that you came for. So that is the power of regions and headings. Other good stuff is that, you know, this is maybe another funny stuff that I maybe I can show you. Yes, I can show it. Yeah. We have multi content, a multi language content here. You know, here if I want to go. Bienvenito. I mean, that is the sound of Spanish, but when I get there. I am outside that region. I am erring down to that Spanish section and then see that the content change. Accessible university that left parody way, right there in the universe. Oh, sorry, it didn't work. I did expect that the change, but I think we had recently some changes here in this section. And I have to do that, but it should have switched to Spanish. Is that your web case, these ratchets, and then the problem is the logic? No, it didn't. Am I using the right screen reader? Yes. Okay. Yeah, I think this is the problem is the code. And then we will fix it, but but again, it should have changed the language because we were supposed to use the proper language attribute for this section and then which automatically tell the screen reader, hey, I'm Spanish and screen reader, you know, can change that on the fly. Escape. I told you about accessible graphics. I am checking the list of the graphics here. Providing an alt text is an art. I think my colleague, they provide some webinar on it. And I strongly encourage everyone to go that it is really not, it requires some training, how to provide alt text and effective alt text for a graphic. Yes, there are sometimes some gray area, hey, is this the graphic is, you know, alt is informational or decorative or stylistic. Yeah, sometimes they don't, they don't, there is not a strong opinion always. For example, I see that here, two students talking in front of, for example, a specific hall. Is it informational? Yeah. If you ask me, no, but some people might have some other opinion. But definitely there are graphics that are stylistic, you know, like a borderline, like, you know, some divider, those stuff, and those things, they definitely need to be labeled as a stylistic. And then the code is so simple, I mean, the attribute alt equal code, code with no space, nothing. And then that sets the alt text to be the stylistic graphic. And when a screen reader sees that, they ignore it, because it's a very, that is how it works. I can take also with the form I have. There is also a form here. And then let us listen together when I tap to it. It says the name edit popup. So it means, you know, I can interact with it, I say, Adi. Okay, that is another field that says that it is clearly said that email country. It specifies the, you know, a checkbox element and read the label. And told me the state of that. So for these elements on the web, we usually need the role, you know, the attribute, the role, name, and state. So it tells me this is a checkbox. Computer science, checkbox, not check. Computer science is the name. Checkbox is the type of the element. And not check is the state of it. So I press the spacebar, it checked that. And when I ask my screen reader to read it back to me, it says a computer science checkbox, checked this time. So it means it's a computer science. The name checkbox is the type of element and then checked is the state of that. So and then if I tap forward. So submit button. Yeah, you see that? These are accessible version of this site. As I said, we have a link inside this page that takes you to the inaccessible version. And then you, when you checked, you have the, you want some fun activity, you know, can go there and see that, you know, how little information you get from the page. Okay. I make a mistake purposely. Why? You see that these are dynamic stuff that I told you earlier. So this is a lot of things are having some dynamic events are happening on the page. And it is leading the content to me. My focus is just on that edit box. But the, the, the person who wrote this app, which was all terium, I mean, they, he made it accessible by providing an aria live and communicating that error message to me. Is that purple? And this is a confirmation. So again, when you are testing that, make sure that, that all the forms must have a label. And then, then also, you have to be able to recover from the error messages and you have to give a confirmation that the site, I mean, the form has been submitted successfully. I'm sure you have seen that sometimes you go to a complicated form to submit and you get back to the landing page. You have no confirmation. Did I submit that correctly or not? Did it go through or not? Because you don't have any confirmation. I'm back here. 153. I'll show you one more thing with the table. So I'm telling my screen reader, take me to the next table. This is a table. Remember when we are navigating table, we see only one cell at the time, one cell data at the time. So it is important the relationship between cell and then row and column header are defined and implemented correctly. Otherwise, we will be hearing just the cell and not knowing what that cell is associated with. So I hope you can hear that. So you got last year computer science. Last year English. But the number, I mean, I am just on the cell where it says that 84. But the screen reader is obtaining information through the browser DOM and reads the relationship between this cell and corresponding column headers. Last year economics, 273, column 4. So last year physics, 69. Last year physics, we have 69. Last year typology, 312. And so on. This year computer science, 300. Now we get to this year. Right? And then it clearly said that this year English 64. And then again, this is the beauty of the accessible coding practice. And then we have a lot of resources to share with you. And then I'm pretty sure I think Anna Marie will send you all those people who register their slides. Please consult the resource section of it with some of these tools. And then something that I wanted also to share with you. We have, we have been celebrating Global Accessibility Awareness Day since 2017. And then this is a day that we focus on accessibility. And then we have a lot of fun activity. And please watch for the communication through our mailing list liaison or other lists about that event. And we would love to see you there and have the chance to talk with you or see you participate in some of those activities. That's it so far what I had to share with you. I can go for another two, three hours. But I think your lifetime is limited. I stop here and ask if you have any questions. I have a question, Hadi. This last example that you have shown us, and it says last year that spans four columns. And then underneath that it has computer science, engineering, etc. Are those table headers, those two rows, both table headers? Correct. They are associated with two table headers. Because in table realm, we are sometimes dealing with the simple table or unified table. We have a number of column and rows. That has a simpler technique. You can just use TH for the column header. And then use calls. Very basic stuff. But for this table, which has multiple calls span, then we have to use a slightly different technique. And each cell must be connected to the relevant column headers. Yes. So then when the screen reader sees that it is a span, it continues to read that first table header when it reads the one below it. It sounded like. Depending on how it has been implemented. Yes. If you go to each data set, you will see that the idea of those column headers that it reads. I see. Okay. Perfect. Thank you so much. Questions. And I should also mention, if you have some pages for testing or website and application, we will be glad to meet with you and then walk you through that and then testing together. And I have one more announcement. Some of you might be aware of the monthly web accessibility and usability meetup that happens usually on the second Thursday of each month. And we are running that for almost a decade. And then tomorrow, we have actually our next one is tomorrow at 10. And then I invite everyone to join us. If the topic is very interesting, it is about using alt text with the picture of the photos of the providers. How much information you can provide or what you should provide in your alt text for pictures of provider or colleagues from UW Medicine are driving that discussion. And we would love to see you there. It is, I think, interesting for everyone. Questions. Do you have any questions? Do you see any questions in the chat? We do not have any questions in the chat. We do have a couple of thank yous. Thank you for coming. I appreciate that. It is always a pleasure having the opportunity to talk with you. So if not, then I wish you all a wonderful rest of the afternoon and then talk with you next time. And thank you very much for coming.