 Okay, good afternoon everyone. Welcome to our webinar series. My name is Hadi Rangin. Without looking at your names, I believe I have the chance to meet most of you or many of you. Then if not, then nice meeting you all. For those of you who do not know me or haven't the chance to meet, my name is Hadi Rangin. I'm a member of IT accessibility team, along with Anna Marie, Gaby, Dan, Terrell. And then we have been taking care of the accessibility problem of campus. My primary job, my primary job, I know, the reason that I'm getting interrupted when everybody comes in or does send a chat, you know, I get through it, it's very interrupted. My primary job is to make sure the software that we develop here or the purchase are accessible. And then that's why I had the chance to meet with a lot of on-campus developers as well as third-party vendors and then testing and evaluating their software. So we are good at scrutinizing the application and then finding all possible bugs and then we communicate that to the vendors or the on-campus developers to resolve those issues. Today we will be talking about accessibility testing with the focus on accessibility testing with screen reader. So you will see that, you know, it is not easy to do that accessibility testing with screen reader. But let me share with you what we have today, what we are going to talk about. So first I will be discussing a little bit about the difference between functional and technical accessibility. Then we talk about, you know, what and then how we test. And I will introduce a few screen reader to you and then toward the end we will have the live demo. And then I promise to leave the last 10 minutes for the QA. Dan and Emory feel free to interrupt me when we are, you know, at the 30 minutes into the session. So I can plan accordingly. So what is technical accessibility? There are two methodology that we use for testing. One of them, you know, we use them parallel. The first one is the technical accessibility methodology. We examine each element to make sure the coding practice is according to the existing standards. And then we use the WCAG content accessibility guideline for compliance and for the standard. What does it mean that it means that for us that the element that we test, which might be a button or menu or graphic or anything that you see on the work environment. They have the proper elementation. This would mean that all the user, mouse user, keyboard user, assistive technology user can interact with that element. So it is one element at the time that we check. So but as you can clearly see that it does not give us a holistic view of overall accessibility of the application. Just tell us, you know, how accessible is that specific element that you are testing. On the other hand, we have also the functional accessibility methodology that in that methodology or in that testing. We identify, we call that functional tasks for the common functional tasks for a given application. And this is usually done with the help of the service manager of the product that we are using the people who are developing. For example, if you consider an email program. There are many common tasks that we can define for them. One of them could be just sending an email. And that sending process, sending an email starts with locating the compose button, clicking on it, going through the email header forms like to CCBCC, you know, subject attachment, if we have going into the body of the email. We're doing the necessary formatting or styling stuff that we want. And then finally, no spell check, and then sending and receiving the confirmation that email has been successfully sent. So, let me give an anomaly, can you disable the waiting room so people just can join without going to the waiting. Thank you. This functional accessibility evaluation this method looks gives us any holistic view of the application, because it really doesn't help us if just single elements of the application of the interface are accessible. We need that the entire process from a to Z is accessible. So, conclusion is that the technical accessibility is necessary, but it's not sufficient. So, in order to have a successful accessibility results, we need to pass both technical functional accessibility testing. Yeah, and I'm being asked usually how hit how I want to test with a screen reader, how we can do it. I usually say that please do not wait, let people who are using a screen reader program on a regular basis, and have good understanding about behavior of screen reader program help you with that. It is a complicated application. And then, so without really knowing enough about this, no screen reader, it's you might get a lot of false positive results, and then could cause some confusion. And then might not be correct. So when we do the testing. First, we need to make sure that we have good understanding first about the basic coding practices. As I mentioned, I mentioned that the big content accessibility guideline. There are a lot of best practices for each elements that we are using on the web. And there are certain standards that we have to follow. Otherwise, you know, browser, and then assistive technology program wouldn't be able to render the same information. So we have to all follow the same standard. The problem is that unfortunately some developers they go and then they build their own custom widgets for custom elements for function that that looks like a function that they want. But it doesn't communicate properly with the assistive technology or even browser. So we are always recommending use the standard widgets that is offered by our best practices. And then, again, that is, that is something that we need some familiarity with the coding practices before we dive into accessibility testing. No functional. Focusing on functional accessibility is really important. And then you should not get lost into just technical accessibility issues because as I mentioned that it only ensures the accessibility of that element by itself. And of course, in this, when we are doing that, we are considering universal design, not one that we are just screen reader accessible keyboard accessible mouse accessible, we want a balanced approach that everybody can access, but that means they use or access over to act to interact with the information of their website or web application. They have very similar and equally pleasant experience. I mentioned earlier function technical accessibility is required for to ensure the overall accessibility of the application. There are many tools out there that they can have you with it. The list of the presentation, we have the list of resources and we will be sharing this slide with all the participants. You do not need to take note about them because all of them are there. And those accessibility testing tool, they can give us up to the most I would say that 30% 30% of accessibility issues. Which is good, but there are 70 plus more percentage that we have to check manually. Frequently, when we meet with developers, and then or the designer, they would like to impose their design or their implementation and say that it but you know, you the screen reader, we know that there are some problems yet, but it's clearly there can go around and do this and that. I mean, these are work around solution. There are many ways to interact with the application. But the usual way is that you know your approach from top to bottom. Sometime, we see that you know we have some interfaces that when you trigger the function, it exposes some information or some elements before that element that you are just click. And then if screen reader user doesn't know what's happening, they have to go and scan the entire page about the changes. Yes, we can say that this is technically accessible. But if we incorporate the time and the efficiency in this process, then we definitely are not functionally accessible. So I am very opposed to finding work around solution. And then and selling them as a kind of work as accessibility solution. So please note that we need to consider efficiency and effectiveness of interaction in our accessibility testing. Okay, before me, before testing, before we, sorry. Then, can you, my colleague, can you go to security and disable the waiting? Thank you. First, I mean, one of the first thing that we do that is that there's a consistent. So an app. No, it is not one single page always there are a lot of pages that they have to go to true. And then since accessibility is not just for a screen reader user for everybody and we want to make sure that at least visually, they are consistent. I mean, it is consistent when you go from one page to the child page or subsequent page, you want to feel that you can identify that page and can see that you are in the same domain and are being the task that you started from the previous page. You have experienced that when you click on one page or within the process, and you are faced with the page that, you know, they are taking you to a completely different domain and different looking field, and then you are asking yourself the same page or different page. So a good example is that when you go to the city of Seattle or King County, and you will see a lot of them, you know, for a single, for example, simple process, for example renewing your license, you will see that they take you to four different vendors behind the scene and every page is different. So if you do not know that you think that you will be definitely lost. So after the visual consistency, we check also for the functional consistency. This means that you mean for the same functions, for example, checking for just a simple thing like, you know, when you are asking, you are asked about first name, last name, gender, phone number, something like that. We would like to see the same implementation. You will be surprised how many times. Yeah, I interrupt for a moment. Could you please close the live transcription has been enabled message on your screen please is not this one right. Yes, it's on this screen that you just had up. Can't get there. So you cannot cross control anyone of you was control. Then gave me an anomaly. I don't see it. It's not, it's not turned on for the meeting. Sorry guys for the interruption but let me see that how I can get rid of that because I doesn't gain focus usually does but. No, I can. It's all right. Move. Move on. Is it very annoying. It's right across the top of the of your screen chair. There's not much we can do about it. Without restarting the whole meeting which we want to do. That's okay your your contents fully visible it's just across. Okay, sorry guys for inconvenience. But the promise that we will be sharing this side to have access to the original slide. So, I was telling you about the functional consistency as I was giving an example you see that for the same question sometimes they use different type of different widgets for example one page. They ask for, for example, gender, and then you see that they use the radio button, you know, may female or not want to disclose or something like that as a radio group that you can choose one. And then you see that the name a different page between the same domain part of the same process. Then you see that they are using combo box. The reason that we are checking for this functional accessibility, this functional consistency is that, you know, for everybody that doesn't matter is excited and not cited disabled or not disabled. There is a learning curve of a time phase that you familiarize the page. And, but this learning curve is significantly longer for a screen reader user. So if I am used to seeing this domain radio group to select the gender, I would like to see that across the entire. So consistency in the functional consistency is really important. Proper use of element is another thing that is, you will be surprised. Or maybe not those of you have, I had the chance to work with you. You will see that a lot of time developers, they confuse button with links, they use them to change it. Or, you know, you have a series of button, for example, back, cancel, submit, something like that. But you see that, you know, one of them is linked, two of them was buttons or vice versa. So it is really a mix. They look visually, they make sure they look like, you know, identical, they look identical. But unfortunately, behind the scene, we see a screen reader see the information behind the scene. And then if it's something with a link, we remain, they remain linked regardless how you, how much you try to paint it. Keyboard operability is another thing that we test. So we make sure that you can perform, you can, you can get to all the elements on, I'm not saying yourself, all elements for the given task. And then you can perform the task from A to Z just with the keyboard. You won't get stuck somewhere else, hey, you know, Dan come and click here for me. He has heard many times from me. And then, of course, it is a requirement that when you are doing with a keyboard, working with a keyboard, always emphasize always the elements and focus must be visible, must be visible. So you should never lose the focus indicator. And then, of course, when you are tabbing, and you are a keyboard user, you are a tabbing, you want that the tabbing goes in a logical way in a way that it is presented to you. And if you are the keyboard user, I'm pretty sure you have experience at some time. This is a keyboard tabbing bounces, you know, goes right top, bottom, you know, they don't go in a proper order as they are presented to you. And a clarification about the shortcut keys, many developers, they have that misconception, I would call that, that they think the shortcut keys would resolve all the problems. And shortcut keys are not considered as accessibility solutions. They are good things to have, but they are not a solution that we promote. They are good as long as handful, and they are consistent. And they work, and they don't have any interference with the assistive technology shortcut keys browser or operating system. And the other thing that we check is our your landmark, the simplest definition of your landmark that I have for you is that I would say that there is a logic that there is a means to structure the application. Practically you put the application in predefined logical box. For example, you have a page and that has banner on the top. You might have a navigation underneath of your banner. You might have another navigation on the left side, and the rest of the information might be considered as a main content. So, as I mentioned earlier, there are seven, I mean there are predefined regions that provide meaning to their application. So, when you come with a page within a fraction of a second, you can see how the page is constructed. You can see the banner, you can see the navigation bars, you can see the main content area, you can see the footer and other information. This information are not available in the way that you see to screen reader user. So, by providing the area landmark, you give a big picture of your application and you can introduce the major component of your application framework. So, as I said, there are seven predefined regions and then they help us to identify here I am in the banner and the main content area or I am, you know, in a footer section or whatever. So, Mecheck, I know that this is not the place for to learn about the area, but we'd be glad to meet with everyone to go through that. Mecheck for the integrity of the area landmark, making sure that everything is, every content goes into your content region. This is no orphan, we call that orphan content, I mean, abandoned content. And we check for the meaning of, or check that if the labels are meaningful. Adi, we are at the 330 mark. Thank you. So, for the, we usually use area landmark to check the integrity or structure of the application, and we use headings to check the structure, the structure of the content, the information that goes in. For those of you who are familiar with accessibility, you probably heard it many times from us or from, and from your different channel, we want the headings or hierarchical, you know, six level of HTML, I mean, heading level in HTML and one to six. And we would like that every heading, every page has a unique heading one, and any sub any major section has a preceding heading two, and each, if any of your major section has a subsection divided into subsections and they need to have heading three, and so on. So heading must be meaningful. So when we see the name, we can, we can identify what it means. If you tell me, for example, S25J3, you know, it is not a meaningful label. It is completeness. Some developers they think, you know, they put a couple of headings here on there. They think they are done. Yeah, it is good stuff, but it is not complete. With the completeness, we mean that we need a heading for each major section. Remember, this heading, it should provide an outline of your content. So you can, if you are a developer, if you are a content creator, you can see the list of your headings. And if you think the list of your heading is hierarchical, meaningful, and gives you a good outline of the page, then you are in a good shape. Other stuff, grouping of the relevant items. This is another thing that we check for. You know, if you try to mimic a list without using the list properly, it is a failure. Doesn't matter how much you try, how much good painter you are, a list or not rendered as list, if you are not using the list element. Graphics. So we would like that we have a meaningful graphic, meaningful label for informational graphic. If you are using, we are not saying that not use graphic for a stylistic effect. Use it. But you need to make sure that you provide, you know, you know, the proper art attribute for that which is all equal quote quote meaning blank or nothing. This would tell the screen reader, this is a stylistic image, so they can, they can easily, they don't even render. But you need to provide a meaningful label for informational graphics. I will have a good example, let's say a few good examples for fun. Forms. Yeah. Missing the form labels, it is crying. So be careful. Make sure that your phones have proper label element, proper labels. And then this is a nice easy task. You can use these accessibility checking tools and they can most of them, they can provide you with a good information about missing labels. And then one thing that we checked up and are dealing with three tests when we are dealing with the accessibility testing is that we try to scrutinize the application purposefully make a failure, make a mistake. And you will see that how those mistakes, how the errors of warnings are communicated to us. And then what is the path of recovery. And then I'll tell you this, we have discovered many really bugs in that, in that realm. Dynamic elements, you know, these are the most, one of the most complicated elements of the web, you know, you click on something, some content changes, some element appears. And then how you communicate those information to a screen reader user who can see only one element at a time or what, you know, how verbose you want to be. And this is also another, another difficult area with accessibility. Okay, now, we're getting to the, you know, the screen reader testing or a screen reader, you know, we have many screen reader in Windows environment, starting with JAWS, which is a commercial one, and then it costs a lot of money. And then we're getting over almost $1,000. NBDA is a free one. And then the optional donation if you want. And then the narrator that has made significant improvement in the past couple of years. In the environment or iOS, they have voiceover. Note that accessibility voice, I mean voice over voice over in iOS and Mac, they work very differently. And for the Android, we have touch back. This is the list of the statistics of the screen reader user that, you know, the statistics of which screen reader you use in North America. I don't think it's North America. It is a global. But you know, it is not complete. And of course it is only the data has been provided by real user, how many users haven't heard about this survey. We do not know. But they have been conducting the survey for many years. And then this is the 2021 survey. So JAWS, which is a commercial one is at the 53.7% NBDA is about 30% and voice over is about 6.5%. And then I think I will talk about that in the next slide. One thing I want to emphasize that screen reader user is not made for testing. It is used. It is made for people like myself who is blind to access the information, electronic information. So a lot of times screen reader, they have complicated, I will call it algorithm to compensate for the lack of accessibility features. So they, that's why that is why some of them are like JAWS is so expensive. They, for example, when you go if on a form and then developer has failed to provide the label, then that screen reader program, they try, it tries to find the closest text to it and provides that as a label. Sometimes they are right. Sometimes it is not. Testing with a screen reader, if you do not know that how a screen reader works, what mode you are can give you a lot of wrong results. We have a lot of hundreds, really, I'm saying hundreds of functions that user can customize it to their need. And then the customization that I use, very likely it is not suitable for another colleague, because we might have different way of interacting and different usage. And then this is new, but I wanted to share with you, we are planning to offer a workshop, a happy day workshop for each screen reader program training in January. And the goal is that at this time we do that with JAWS and NVDA, but we will be glad to add also voiceover and then talk back if needed. I think I will do that also voiceover for Mac, but for mobile, I think we have to see that how many, how much demand. The screen reader have two major modes, reading mode and form mode. And each program, they might have different vocabularies. What does it mean? You know the information that you see on the screen, you see an element with all the surrounding information, but screen reader program, a user like me, they see only one element at a time. We see only one link at a time, we see one button at a time, we see one menu at a time, menu item at a time, list item at a time, graphics and so on. We have no information about the surrounding elements, unless these things are provided in a programmatic way. So, in order for us to see the page in a context, then we need to be in a kind of reading mode. By default, keyboard user can only go to just focusable elements. They can go to tabs, they can go to, for example, a button or menu, but they cannot go to a good link, but they cannot go to a static text. But static text is part of the page. So, when we are in the browse mode, we can read the information from left to right, top to bottom, depending on how behind the scene, how the page is constructed. The terminology that we use is called linearize. We linearize the content or screen reader, linearize the content from left to right, top to bottom, again based on the coding that they have used that. And that's how we read and discover the page. In this mode, when I am, for example, on a specific page and I'm reading that, so I can do that some limited interaction. For example, when I go and reading some text and it tells me here to see the, for example, that website click here, I can click on that link and go there without leaving my mode, which is reading mode. However, if I want to have full exposure, full interaction, then I need to switch from browse mode to full mode. In this mode, screen reader is now passing everything to the browser. So it is not intervening, it is not intercepting any keys that you type. So it is like a keyboard user. But the problem is that we do not see in that mode the static information. For example, if you have a form control, like a text box, and then it has some instruction associated with it, we do not see it, unless it is programmatically connected. Okay, so we will talk about that if you, you know, when we offer the workshop, and then we will go through all those details in four hours. Now, answer to this question, can I use a screen reader? I would say that yes, but with the caveat that we have to, there are a lot of conditions to it. It is not designed for accessibility, to test for accessibility. We, the best way to use them is to verify accessibility issues, not to determine accessibility issues. It is not for keyboard operability because screen reader, they provide, you know, for example, I have never been good in checking the keyboard operability because I have to use a screen reader program. My screen reader program, they add some functionality that helps me to get some elements that Dan, as a non-screen reader user, cannot do it. So, he's mostly a keyboard user, which we cannot use it for keyboard operability. And then, again, you have to be careful to know that you don't get this false positive result and you have to really know all those limitations. We occasionally hear from people, ooh, it is jobs accessible. We don't have such terminology like this. So, forget about it. If somebody says that, so they are not completely in line with accessibility testing. Bottom line, don't use it for testing, but you can use it for to verify the accessibility findings. So, there are, I think this is redundant, we, I have discussed about these elements in this slide. I can escape it. And this is a list of the, I call the survival command. Some of you probably heard that story from me. I had many, at least five colleagues who started for the first time Android or a touchpad or voiceover on their iPhone. And then they didn't know how to turn it off. Because once you have started the behavior of the device changes, and then if you are not familiar, you won't be able to turn off your screen reader. So, these are the series of commands. I put that that I make a direct comparison between NBDA and JAWS, that you can see them when you receive the slides. So, there are three pages. Now, which is we get a fun part of the presentation. I'm planning to show you two pages. Okay. Here. A good page. Okay, I think apparently I could lose the other one. But let's just go with it is fun. Let me go back there. It is not working. Let's do that with this page. We don't have very much time either. So as I mentioned, the one of the things that we do when we get to this page, I need to disconnect it so you can hear that. I need to disconnect my headset. Okay, is it loud enough? Is it loud enough? Hopefully. Yes, I think so. Okay, that's great. So the first thing that I mentioned that earlier after this visual, you know, consistency and then functional consistency. Is the, you know, our your landmark security there, as I mentioned, I have offers a hundreds of functions. One of them is to show me the list of the landmark or regions on this page. And I'm going to call that function. That is the list of they are your regions for those of you are familiar. You can laugh. I can, I can, I can hear that it is navigation navigation region navigation navigation navigation navigation. So what is the difference between this navigation navigation. So again, that is something that we can laugh about it, but you know, indeed we should cry. So, I hope that we can have the chance to meet with them and the talk with them and then show them some of the highlights of some of the accessibility issues. There are main, the main region is missing. The main region is the area where we put the main content. The real information. So it is not. So it is, it is pretty useless. So I say my next means to access that to do get information here is check a call for the list of the headings. They started the heading one. The number that you see on the right, it tells me the heading. And that is a way how I, how I can connect these pieces that for example, I can say this heading to is a child of heading one. I know a place to explore like a local call it to three of thirty five. I go further down. Thanks to do call it to four of thirty. I don't go to call it to travel advisory call it to seven of thirty five plan your trip call it to eight of thirty five call it for nine of thirty five. As you see, we don't have any heading three is three. Now here is where we really get lost here. Did the developer fail to provide a heading three or her heading four is just a random heading. Then we lose the relationship between this page between the information pieces of information. So remember the support is left. It's supposed to give it an outline of the content, but let's go further down. So I hope it makes it clear how many people they use is heading level. So randomly, how confusing it can be because we never can conclude the relationship between the information here, the piece of information. To have another fun is the list of the graphics. Select the graphic dialogue. Okay. Yeah, it's interesting. It doesn't tell me about the content of the graphic. Anything, but it tells me what company or what person has taken that without any information. Now I am asking myself, is it really the what is behind it? Is it is this really the information graphics that I should know? Or it is just a piece of no statistic information. Sponsor logo. The next one. Sponsor logo. So how why is it important if I do not know who is the sponsor? Then why should I know? I'm sorry. I'm sorry, you can stop laughing. So it gives you a second. There is a sponsor, but without telling me what the good is the sponsor is. And the last funny part is this one. To get missing image descriptions open the context menu free of free. Okay, so what should they understand of this image? I mean, it is without insulting that it is useless information for a screen reader user. If we were not in the public meeting, I probably use a different vocabulary. Now, let's see that. What a form controls. I told you this is a crime, right? I see that the phones play button to progress. So, for those of you are familiar, I'm taking you through that. I'm taking that. As you probably see that here, because the tap panel widget, I can go left. But none of these tabs, they have been meaningfully denied. I checked with my colleagues and they told me these are just icons. So if I am coming to this vision, and I do not know which tab is which, I mean, this is, I mean, very dangerous. It is useless. This is really useless. I emphasize that it's very useless. And then all these tabs, they should have meaningful labels. They can have graphic. But graphic, you know, it can even be used label for that graphic. But anyway, or they could use graphic behind the background, and then have their meaningful label on the phone for graph. What time is it? 24. I'm sorry. I stopped here. I have a lot of resources that is part of the information here. That's part of the slides. But I would like to respect everybody's time. And then open the floor for the questions. We will, we can stay a little longer for those of you who can make it, but feel free, ask your question, or Anna Marie, if you have received any questions, we will be glad to discuss. We do not have any questions for you at this time. Folks, feel free to go ahead and put your questions in the chat. Open your microphone. It's even better. Okay. You're more interactive. There's a link in the chat for folks right now. This is a link to our webinars archive page from accessible. So from this link, you can access recordings and slide decks from the webinars that we've done this year. We'll get this one up as soon as we can. It usually takes a week or two because we need to send the video out for captioning. And so we want to make sure everything's accessible before we put it up there. I have a question. Howdy, it's Karin. I've been working with you on doc affinity testing. Thank you for your presentation. It was very interesting. I am working with another team that is doing some refactoring of existing systems. And I'm wondering what's the best time for developers to be thinking about the hierarchical nature of the of this process that you outlined. We had had some conversations and our devs have said, oh, we just add the tags at the end, which to me seems like maybe that could work. But I don't know enough about it to know whether it's something that really needs to be considered from the beginning of the process or somewhere. I don't know. So that's my question. It is a great question. Thank you for asking that question. This time to act to add this accessibility is when you have the putting on the behind the napkins. Believe or not, we have we get the best results when the just graphic, I mean just, you know, wireframe and some, some outline of the application, because it is not as we have to mention it is not just one of the single elements. It is about the we have to see that holistically if the application or the task is accessible. I mean, I have seen a lot of developer they put some elements here some elements there, and then they said that here. This is how we want. No, it is it is not it doesn't work that way. If you put that there, you put it and then you have to come come up with a logic. At some time, you know, they put elements that are not related together. Then I asked him, okay, good, you put it there. Now come up with a meaningful label for this group of elements. So it is again, if you want to think about it later, I'm sorry, it will be a lot of redoing and the sound of changing the code, and it will be time consuming and nasty. Thank you. I should clarify that this is a rewrite of an existing system so they have some constraints they can't, you know, they can't design it from the ground. I understand them. But again, we can work with their limitations. But that attitude that way that you know we can do that later later time. I would say that it is significantly more difficult and a lot of redoing the stuff because sometimes it is just you cannot make it accessible if the way that you have designed is accessible. It is inaccessible I would say. Thank you, thank you. Question please. This is, this is Elliot from the UW libraries. So nice to see you here. Thank you for a great presentation as always and I really, really appreciate it just your point of like, you know, for people who are interested like me and testing like to start off with keyboard accessibility really doing like the no mouse stuff and sticking with that. And then I've been trying to learn more about NVDA these past months but I'm keeping it in my mind to use that not so much as I'm going to use NVDA to find things I'm going to use NVDA more to confirm what I'm finding with keyboard testing I've been trying to like, do you have any recommendations for improving my NVDA knowledge so I look at YouTube it's like, I found like some videos but some seem to be good and some seem to be really not good or I'm like slowly learning what h does and k does and insert this insert that do you have recommendations for tutorials to like, responsibly learn about how to use NVDA. Again, you guys need, if you're those of you who want to do that really screen reader testing, you need to change your concept of seeing, you need to see with your ears. I mean, that is that it is very different when you look at your interface and you see where it is and then you target another element. But in a real screen reader world, you do not know where is what. And then discovery of where is what it is the key. And then if somebody asked, ask me what is the most difficult problem in accessibility realm, I would say navigation navigation navigation. I mean, of course, we navigate because we are discovery. Once you can really close your screen. I mean, again, when you see the application, even once, you have some idea about the location of the positions of these functions. But for the screen reader user, they don't have that point of reference. So it is very difficult for a cited user to make it good to become a good screen reader user because they have already some point of reference. But how do you modify jump in here please. For those who haven't met my name is Dan Comden. I work with Hadi and I've been supporting a system technology users for the majority of my life been around screen readers for a long time I am cited. And I still struggle I think screen readers are a unique application compared to pretty much everything else that you have used might have used or have considered using. There are no visual cues or reminders with a screen reader application as to what you can do what your possibilities are. For the most part, there are of course some exceptions here but for the most part, you're what you need to do is memorize keystrokes and, and like Elliot was just saying, you know, just figuring out when to hit H. That's the basic thing but that's you know that's one thing to remember you know add that now add a couple dozen more just for basic usage and so it's a lot to memorize it's not the kind of thing you can just pick up with it with a half an hour of fiddling around. It really is a very different thing and so that's just one of the reasons why we don't encourage folks to jump right into doing screen reader as part of their testing unless unless they actually use it or rely on it and know how it works already. I won't go into much more detail and I want to steal hotties time but it's it it I'm not saying it's impossible it's very challenging, and it's not like any other software that that you've seen you've seen or used before. I appreciate that. I know that the past four or 3pm, 4 or 3pm, but again, I will stay until to answer everybody's question but if you need to leave, feel free to do it. I mean this morning I had a meeting with moral and URL and never learned how to format it properly. For those of you who know this application is super complex and then the company is very much into making the application accessible and we have the pleasure to working with them. No, actually, I cannot make a public comment at this time but the the it's a super complex application for me as a who has not seen that application, even once, even when I was able to see we're able to see that interface only once. I think interaction with it would be extremely easier. But at this time, you know, I don't know how many time my students, they told me about it, but I forget about it. I forget to know what is what, and then because there are too many things to remember. But, but if you see it, and then go and do that purple accessibility testing, if somebody says tells you go and create a for example sticky note, then you know that where you are going. Does it makes an elite what I'm trying to say. I think that's super super helpful and just, you know, thinking back just to my using nvda just these past months and trying to learn about like, Dan you're right, like I feel like I'm taking all these notes about like all these like just it seems like all alone can do a million things and nvda but I feel like I'm using my eyes more than I've ever had to use my eyes as I'm using nvda like trying to figure out where things are how things work and so I can. This is a really interesting conversation and your point to how to just about what applications are like and like you're feeling like if I could just see it for two seconds like to me that is so interesting that there are such divergent experiences happening with these applications as opposed to there being much more cohesive experiences and you know with these things it's really a fascinating conversation. Thank you. Questions, comment. If not, then I would like to thank you for coming to the webinar, and I would like to invite you for, you know, to join our workshop to be announced. For sometime in January, the initial plan is that we do one workshop every week, one for jobs, one for nvda and one for voiceover on Mac, and then possibly if there is demand, you know, you can do that for iOS and then Android. And then the recording will be shared with you within a week or so or more. They probably have more problem with my accent. Sorry for those caffinists. You have to listen sometimes multiple times to find out what I said.