- [Anthony Priore] Good morning and good afternoon everyone. My name is Anthony Priore. I'm the Digital Marketing Specialist at TPGi. We're just gonna wait one more minute as people sign in and we'll get started briefly. Feel free, as we wait, if you wanna share in the chat where you're logging in from in which part of the world, feel free to do that. Love it. We're seeing people from all over the world. We're just gonna give it one more minute. I'm still seeing a few people sign in, so get started very briefly. All right, thank you everyone for joining us today for our webinar, Ramping Up Your Accessibility Testing: A Beginner's Guide with TPGi's Gigi Etienne, an Accessibility Engineer. Before we get started, I have a few housekeeping items I'd like to get to. So firstly, this session is being recorded, and we will email everyone the recording after the event. Secondly, we have captions available, so feel free to use them as needed. Next, we will have time for a live Q and A later in the webinar, so please use the Q and A box, and we'll answer as many questions as we can at the end of the presentation. We will be monitoring the chat too, but sometimes they can get lost in there, so it would be better if we wanna make sure we can answer all of your questions if you can send them into the Q and A box, that would be great. And then lastly, if anyone needs any Accessibility support training or usability Testing, we will be sending out an email after with a link to schedule a time to speak with one of our experts. So with that, I will let Gigi get started and provide an introduction for herself. Take it away, Gigi.

- Thank you Anthony. Hi everyone, I'm Gigi Etienne. I'm a Social Accessibility Engineer at TPGi, and I'm gonna talk to you today about Ramping Up Your Accessibility Testing: A Beginner's Guide. So I've been an Accessibility Engineer at TPGi for about a year, a year and a half, almost now, and essentially what I do day in and day out is I test audit websites, or products, or mobile apps of our clients, and I test for their Accessibility issues. I see if they have any Accessibility issues, what they are, and then I provide some feedback to the clients so that they can fix those Accessibility issues and make their products more accessible for their users. And in today's presentation, what I'm gonna try to do is provide a simplified method for Accessibility Testing. Some of you might be familiar with WCAG, which is the Web Content Accessibility Guidelines. It's a bit like a Bible to us Accessibility people, Accessibility professionals. And it's what we use to determine whether something is accessible or not. It's a set of international rules that we use for that, but that can be, if you are familiar with WCAG, it can be heavy. It can be a lot of information, and it can be very confusing if you're getting started with Accessibility, or if you just wanna know if something is roughly accessible or not. And so, what I'm attempting to do with the presentation today is to give you a five step process, simplified Testing process, that you can take away, and then use in your own time, so whether you are working inside a company and you wanna check, how accessible is my company, or my product? If you're an entrepreneur, if you wanna make sure that your product is accessible, or if you work already in Accessibility, but you're not necessarily Testing or don't know how to test thoroughly, then this presentation is gonna help you, give you some basic understanding of how to do Testing, and by the end of this presentation, you'll have a good understanding of that, and you'll be able to find most of the Accessibility issues what I'll be able to tell you today, and yeah, hopefully that's helpful. So before we keep going, I wanted to ask you guys, I know we have almost 100 people online, and I wanted to ask you if you can go on the chat right now and tell me, what is your role, what is your title? Do you already work in Accessibility? Are you an engineer, a designer, a copywriter, or do you not work in Accessibility, but you're interested in Accessibility? I'd love to know, what are you guys doing, and just give me an idea, okay? Okay, so Program Lead Accessibility, awesome. Designers, engineers, Superintendent, document tester. Okay, nice. Accessibility Consultant, graphic designer, product design. Okay. Yes, WCAG is heavy. Yeah, Kathy, I agree. Hopefully this is gonna give a bit of an answer to that, a simplified answer, although I'm not saying anything negative about WCAG. I think it is a very helpful piece of information and documentation to have, but it's not, if you're starting, I guess that's my point. QA Testing, okay, awesome. Cool. Wow, so much, okay, great, disability services in a community college. Okay, awesome. Well thank you. Thank you everyone. That's awesome. Great, looking to become an Accessibility tester. Okay, Sherry, well, that'll be helpful for you today, I think. Great, okay. Well, thank you everyone. So good to see so many of you answering here. Let's do that. So it helps me get an idea of who's doing what, and just so I can focus on the important things here. So before I get started as well, I'm gonna reiterate what Anthony said earlier. There's a Q and A box next to the chat, so if you wanna use that to ask your questions, it's gonna make it easier for me to then go to the Q and A box instead of trying to find questions in the chat and the Q and A, and then I'll be able to answer your questions at the end in the Q and A box. So let's do that and hopefully that works for everyone. Great, so in that case, I'm gonna get started. The Testing process that I use, and really like the quick story of how I started using this was because my colleague, I was essentially using WCAG, those guideline I mentioned, one by one, there's like 50 of them, and so I was going like, "Okay, one, one, one, one," and going one by one, and obviously it was taken forever, and it was a lot more complex than it had to be until a colleague of mine, Alicia, told me, "You don't need to be doing that. You just need to be Testing by topics." And so this is essentially the result of that conversation, and a lot of work on my end to sort of simplify it in that way as much as possible. So the five topics that we're gonna look at is colors, resizes, keyboard Testing, code, so what to look at in the code for Accessibility, and screen reader Testing. So we're gonna go one by one, and I'm gonna tell you, what are the key things to look out for in there if you're Testing. So the first thing is colors. There's three things to look out for here. The first one is test text Contrast. So any text that you see on a page that you're auditing, on a website that you're Testing, if it's regular size text, it should have a Color Contrast ratio of 4.5:1, and if it's a large size text, it should have a contrast ratio of 3:1. If it's a non-text contrast, so that's anything for example, like a focus indicator, so something that allows you to know where the focus of the keyboard is placed, or graphical objects, or icons, or close buttons, or things like that, visible things that are important all of that needs to have a ratio, a Color Contrast of 3:1 ratio. The way that you can analyze this, or that you can use the tool to know what ratio elements have is you can use the Color Contrast analyzer tool. It's available on the TPGi website. It's free, and I use it all the time. Basically you can use the color picker over here. You can use it, and you can select the color of the element, or the text and the background, and then you see the Color Contrast of the element with the background, and it's gonna tell you, if it's above the contrast ratio. So here it allows you to see if it's a 1.4.11, so it's a fail of the non-text contrast, or a 1.4.3, which would be a text contrast failure, and so on, so it's pretty self-explanatory. I'd recommend playing around with that tool, but basically, yeah, just remember text contrast and non-text contrast, and the numbers that need to be respected for Color Contrast. And then the last thing to think about when we're looking at colors is the use of color. So use of color is basically no information should be conveyed to the user using color alone. For example, if you're filling out a form, and you make an error in one of the fields, and the error is marked up with the outline of the field becoming red alone, and there's no text or anything else indicating that there's been an error, that's a use of color to indicate, or to give some information to the user, and that should not happen. There should also be, for example, a text saying, "There's an error, please correct it," blah, blah, blah, and so that is use of color. Use of color also should not happen so that colorblind users can also access all of the content, and be aware of an error that they've made in an input field, for example. The second step is resizes. So here you wanna look at four things, reflow, resize, tech spacing, and orientation. I'd recommend here on this one, if you go on the inspect of your web page that you're auditing and then you select, you go here and you basically can set the dimensions of the browser that you wanna look, and so you can set it to the reflow sizes, which is 320x256, or you can say change it to resize, which is 1,024x768, and you can set it to that, and then test that way. So for reflow, you just resize it to that, and all of the content of the part that you're auditing should be fully visible like it is when it's not on reflow mode, and for resize, you need to set it to those dimensions and then zoom in to 100%, and at that point, all of the contents should still continue to be visible to all users. For tech spacing, you wanna apply tech spacing properties, which is, they're listed on the slides. The slides have already been sent to you guys, so should be available to you. You should have them by now, but basically when you apply the tech spacing properties, the content again should be all visible on the page. There should not be any overlap of text over text and things like that. And then last but not least, for the resizes, it's orientation, and orientation means that the content, and this is mostly the case for mobile Testing, but it means that all of the content should be available both in portrait and landscape mode. This is important for users who, for example, will fix an iPad or a phone on something in front of them, and they're not necessarily using their hands to navigate or a screen reader necessarily to navigate, but they wanna be able to have it mounted in front of them, so all of the content should be available in both portrait and landscapes so that if you put it in one or the other direction, then the content is available to them as well. The step three in this process is keyboard Testing. So this is one that has four key things to look at. One is keyboard. Can everything that is an interactive element on my page or on the part of the page that I'm looking at, can everything that is an interactive element, can it be reached and operated with the keyboard? So the way that you test that is with a tab, with the tab key, and the shift tab keys on your keyboard, you should be able to get to every single interactive element, so every link and every button, anything that you can interact with on the page with the mouse, you should also be able to interact with using the keyboard. You should also not have any keyboard traps, so this happens a lot when you have, for example, an external plugin that's put into the page. That's not the only case when it happens, but it's an example, and the user might get to a point of the website or might get into the plugin, and then they're not able to get out of the plugin using the keyboard alone, so it's very important that there are no such situations. There are no keyboard traps in the website that you're auditing. Focus order is the other thing to look out for, so the order in which interactive elements are receiving focus needs to be logical. So you cannot have the first bottom at the bottom of the page receiving in focus, and then jumping back to the top, and then to the middle, and then again. The logical way that elements or interactive elements receive focus is from top to bottom and left to right for most of the websites that you'll be auditing, and so essentially you should make sure that all the elements are receiving focus in that order. And last but not least, for keyboard is visible focus. All of the interactive elements that receive focus should have a visible indication of focus, so the user should know at all times visibly where the focus is placed. And so if you have an element, a button for example, that receives focus, but if there is no visible indication of focus, so how is the user supposed to know what button has the focus in that moment, right, so that's also very important. I'll share a quick tip with you guys of how I do this, and, especially for the focus order and the visible focus, it's very helpful to know, sometimes you'll have an element that is receiving focus, but it's not visible, and so you wanna know if it is actually receiving focus, or if it's not visible, and so a way of knowing this is using document.ActiveElement. So if you go in your inspect of the website you're auditing, and you'll go under the consult tab, and then there's a little I button there that's called Create Live Expression, so if you click on that, and then type document.ActiveElement, and then click enter, then you can use still the tab and shift tab keys, and it will tell, you at the bottom, just under the the tabs right there under the tabs of the elements and consult tabs, it will tell you what is the element in that moment that is receiving focus, so if you keep going tab, it's gonna change the elements from one element to another, telling you which one is receiving focus, and that's a very helpful way to know also, for example, if you see that there's a hidden element, it's not visually there on the page, but something is receiving focus, and you don't know what that is. That is a focus order failure, so you're gonna need to detect what that element is, and so using document.ActiveElement is a very helpful tip to know, what is that hidden element that is receiving focus. And just to dive a little deeper into the keyboard stuff, here's a few reasons why some elements who should be receiving keyboard focus are not necessarily receiving keyboard focus, so it might help you give an explanation as to why that is happening. So if you see a link that works with the mouse, but it doesn't work with keyboard, check for the href element inside that link or inside that anchor element. So it might be that the anchor element does not have an href attribute inside it, and so therefore it's not gonna be receiving keyboard focus, so that's something to look out for, for example. Another one is a non-HTML focusable element that doesn't have tab index zero. So we're gonna talk about tab index in a second, so that's gonna make a bit more sense then, but if you have a <div> or <span> element with say, for example, a role button, but it doesn't have tab index zero, it's not gonna be in the focus order, and it's not gonna receive keyboard focus, because it's not a native HTML element that's being used. It's a <div> or a <span> that they do not receive keyboard focus naturally. They have to have tab index zero to receive keyboard focus, so that's another explanation. And also an element that has tab index equals minus one would also not be receiving keyboard focus. So we've talked about tab index and I wanna explain very briefly what that is. Some of you may already be familiar with that, but I think this is a quick explanation. Essentially tab index is an attribute that can have three values, it can have a zero, it can have positive values, or it can have a negative minus one value. Tab index zero, what it does is it includes an element in the natural tab order, so if we take the example of just now where we have, instead of having a button with a button element, the HTML button element, we have a dev with role button, the <div> does not naturally receive keyboard focus, so you're gonna have to give it tab index zero so that it's gonna receive keyboard focus, and so that's when tab index zero is very helpful, right? The problem is you have to be careful of how that tab index zero is used. You might come across, for example, a paragraph, a piece of text that is receiving focus. That is clearly not an interactive element. It should not be receiving focus, and it might be receiving focus because it has tab index zero set to it. So you're not only looking for things that should be receiving focus but are not, but also for things that are receiving focus, and should not receive focus, so that's also a part of Testing for a keyboard. Tab index equals positive values one, two, three, four, five, et cetera should never be used, so you might come across this, which basically means that the developer that wrote that does not understand how tab index zero works, because you should not have positive values in using tab index. It should quite simply be avoided. The misunderstanding, most of the cases when I've seen it, they think that in order to give an order of focus order to the page, they have to one, two, three, four, five in the order in which elements should be receiving focus, but focus is already happening naturally from top to bottom, left to right, so we should not be interfering with that. We should just be giving a tab index zero for something that should be interactive and is not naturally interactive. That's the only application for it. Now, tab index minus one is interesting. It basically gives programmatic focus to an element, but it doesn't include it in the tab order, so I'm not gonna go into much detail for this one, but it essentially, imagine a model dialogue that is triggered by a button, that dialogue that appears out of a sudden cannot have focus immediate all the time, because otherwise it would be visually hidden elements that receive focus, but when the triggering element is triggered, and the dialogue opens, then that dialogue is gonna have tab index minus one, which means that it's gonna programmatically receive focus at that moment when it opens, it does receive focus, and that's the way it should be. So yeah, that's a quick explanation of tab index. hopefully that's clear, but yeah, let me know. The step four for the Testing process is the code. I usually, when I'm Testing web, I will usually look at the code first, and I'm able to detect like 90% of issues just by looking at the code without Testing screen readers or without Testing even with a keyboard or anything like that. Obviously I'm gonna go through all the steps, but looking at the code is gonna help me see most of the issues. If you're not familiar with code, don't worry. It's not very complex. I wasn't familiar with code a year and a half ago either, but once you start detecting what the issues are, it's gonna be the same thing over and over again, and you just get good at detecting those specific Accessibility issues in the code. So the first thing is headings. If you see a heading on a page visually, then it should also be marked up programmatically. So if you think about a newspaper, if you're opening a digital newspaper, and you're looking, you're first gonna look at all the headings, and you're gonna then decide, based on the headings, you're gonna decide what is the article that you wanna read. Well, it's the same thing for screen reader users, they can navigate using headings as well, but for that to be the case, the headings need to be marked up programmatically in the code as headings, and that is done with the <h1>, <h2>, <h3>, et cetera elements, so that's very important, but also the order in which the headings are marked up is also very important, so you cannot have a <h3> heading at the top followed by an <h1> followed by an <h2>, et cetera. It should be, <h1> followed by <h2>, <h3>, <h4>, et cetera, et cetera, so the order is also important. Cool. The lists are also a big part of what you can see when you're text Testing with the code, or you're looking at the code. Anything, for example, imagine a list of links, like I have a screenshot of inside on the screen. It's a list of links that we have at the bottom, at the footer of our TPGi website, and that has to be also be marked up in the code as a list. The most common type of list is an unordered list, so you use the ul elements, and each element will have an le element with the element inside, with the link, for example, in this case, inside the le, and that means that it's gonna be announced as a list with XYZ number of elements inside that list. There's another type of list which is ordered list. So that's, for example, if you're doing a recipe, and the list of things has to be in a particular order, one, two, three, four, five, that's when you would use an ordered list, but then again, most of the lists that we come across are unordered lists. Another thing to look at is images, so there's two types of images. There is decorative images and informative images. Informative images are images that are giving an additional piece of information to the user visually, and so that information that is visually conveyed has to be conveyed to screen reader users as well. The way to do that is you give that image an alternative text with the alt attribute and you give it a value, and that value has to be descriptive of what the image is conveying. The decorative image is an image that is not conveying any additional piece of information visually, and therefore it should be hidden from screen reader users. The way that you hide it from screen reader users is giving it an alt attribute with an MTL value, so that's something that you can look at when you're Testing is looking at, is this image decorative, is it informative, and therefore, if it's informative, does it have the right alternative text? If it's decorative, is it hidden within MTL text? There is, I would say, a certain subjectivity, to what is decorative and what is informative, so we often have debates about that sometimes even so that there is, bear that in mind, but usually the rule is if it's giving you visually an additional piece of information, then it should be conveyed to screen reader users. The labeling, so I'm gonna go back to the chat here, and then I'm gonna ask you if you can tell me, so I have on the screen, I have a first example, which is an anchor element that has an aria label Facebook with the value of Facebook, and then I have a span inside it that is basically the content of the anchor element. It's Twitter, so I have a link with the text Twitter, and inside that same link I have an aria label with the value of Facebook, so can someone tell me what this link is going to be announced as to screen reader users? Okay, I've got a couple people saying Facebook. Yeah, I mean, yeah, that's it basically. Everyone's saying Facebook, thank you. It is, because aria label is gonna be taking precedence over the content of the element, which in this case is Twitter, so even though that element might say Twitter on the page, it's gonna be announced as Facebook to the screen reader, and that would be a failure, because whatever is visually conveyed has to be conveyed to the screen reader user. And then let's go to the second example at the bottom here. So I have a button with a text content yellow with an aria label blue and an aria-labelledby that, sorry, sorry, no, no, no. I have a button with a text content red, aria label blue, and an aria-labelledby linking to a span with the content yellow. What is that going to be announced as? I'm seeing a lot of people saying blue, red. Okay, it's actually yellow. It's actually, yeah, yeah, it's actually yellow because aria-labelledby, in the same way that aria label takes precedence over the content aria-labelledby takes precedence over area label, right, and so that's kind of, it's a hierarchy of labeling. You don't need to get too deep into it as long as you know those couple of rules, that's enough, but basically this button would be announced as yellow when you actually have an aria label in the content, so this is confusing. You're probably never gonna see something like this on a website, but I just wanted to run you through those couple of examples and how you can see, just from the code, from a couple of lines of code, you can see if there's an Accessibility failure here or not. Okay, the next thing that you can look at in the code is grouping controls, so if you have a bunch of check boxes or radio buttons. For example, in a questionnaire and you have a question, and underneath you have three radio buttons for an answer for that. Those radio buttons are clearly visually grouped in that they are under that question, who is the label for the question I guess, and then you have the three buttons that are underneath it. That information has to be conveyed to screen reader users, 'cause otherwise they would just hear, "Radio button, radio button," but they wouldn't know what those radio buttons are. They wouldn't know that they're related to each other, and they wouldn't know which question they're in relation to, and so I'm not gonna go into too much detail here, but when you have, in the first example here, I have a couple of check boxes, and they are not checked, they're just in two separate <div>s but they're not linked with each other. In the second example, I have again, a same example of couple of check boxes, but they are linked, they're all inside a field set element with a legend, which would be the question in our example. And then they have the <div> inside it, but the <fieldset> element is gonna group them all together, and so that's again, something that you can see just by looking at the code. Another important element is the programmatic association of a label on the input field, so if you think about it, I have an example here of a field that says first name is the label and the input field, it says John is the content, and so if a screen reader user lands on that field, and that first name label is not programmatically linked to the text field, they're just gonna hear, "Text field", but they're not gonna know what they're supposed to be entering in that text field, so it's very important that the label is programmatically linked so that when they land on the input field, they go input field, first name, and so then automatically the user knows that they have to enter the first name in that field, so the way you do that is with the id and for attributes, so you'll give the input element, you'll give it an id with a value, and then for the label you'll give it a for attribute with the same value of the id attribute in the input field. It's quite simple. The example again is in the slides if you wanna look at later, but it's essentially straightforward in that you just use the id and for attributes to link the input and the label. And then similarly with error messages, so if you think about a form field, you're entering information into a text field, but you've made an error and there's an error. The error message for example, error, please enter a valid address. That text has to be programmatically linked to the field in error, because otherwise the screen reader user is gonna get to the, "Error, please enter a valid address," but they're not gonna know what field that error message is in relation to. And so that is done using aria-describedby in the input field, and giving it a value that is gonna be the same value that you give to the id in the <span> element that is containing the error field. That is the example that's in the slides, and in the same way that the label has to be linked to the field, the error message also has to be linked using aria-describedby to the input field as well. Last but not least is the fifth step of our Testing process, and it's the screen reader. Quickly, screen readers work sometimes better with some browsers than others, so usually the way that you test is you'd use JAWS. JAWS is the screen reader with Chrome, NVDA with Firefox, and VoiceOver with Safari for iOS devices and TalkBack with Chrome for Android devices, so that's usually how we test. Sometimes we like do a bit of everything, but that's usually the way that you'd wanna test using the different screen readers, and I'm gonna divide this into two things, so by the time I get to the screen reader part of the Testing, I've already looked at colors. I looked at resizes. I looked at keyboard. I looked at all the codes, so I know most of the issues that this component has, right, but I'm going to use the screen reader part of the Testing as a way to confirm all of my issues one, and two, as a way to find out any new issues that I may not have been aware that only this screen reader is gonna be able to give me, and so that's why it's very important to use a screen reader as well as a tester, I have a lot of colleagues who are screen reader user testers themselves, and so they will test using the screen reader alone, and that's a great part of working in the Accessibility industry, but from someone like me, I'm using the screen reader as the last part of the Testing and it's very important to use it, because it's gonna allow me to see some of the issues that I might not have been aware of with everything previous as well, so basically, what I'm trying to say is, don't skip the screen reader testing part. What am I looking for that I already know when I'm Testing with the screen reader? So for example, are decorative images not announced? Informative images have the right alt text? That's all stuff that I already know, but that I'm checking again with the screen reader. Are lists announced as lists? Are headings announced as headings? Do elements have the right role and state? So for example, an element button has the right element like role like button and state, is it checked, not checked, et cetera? Do elements have an accessible name? Does it match the visual label? Are the input fields and the label properly associated? Are error messages associated as well? So that's all stuff that you already are able to see from everything else that we've tested, but that you can check with the screen reader, and then things that you might not have known already by Testing with everything else is, are there any visually hidden content that is announced to screen readers? That's something that you're only ever gonna know by using the screen reader to test. Is the content announced by the screen reader? Is the content announced by the screen reader as it is presented visually? So are there any discrepancies in everything that you're seeing and how it's been ex exposed to screen reader users? And is there new dynamic visual information that is announced to screen reader users or not announced? So for example, you submit a form and there's a status message that appears, successful submission, for example. That status message, it has to be exposed to screen reader users. That information has to be given to screen reader users, so that's, only the screen reader user Testing is gonna allow you to see that part of it. Okay, so in conclusion, this is the process. So first colors, then resizes, three, keyboards, four, code, and five, screen readers. The benefit of this Testing method is that it allows you to group things into these five sections, and it allows you to be a much faster and efficient tester. So I hope that that has been helpful. I'm gonna also leave in the slides, I didn't go too much into the WCAG criteria, but if you're interested and wanna go further in that there's, at the end of the slides, there's a WCAG checklist with what are the exact criteria that each of these part five sections that we talked about correspond to. So if you wanna dive deeper into that, that information is available there, so thank you and I'm gonna look at questions now. So let me open the chat, and I also wanna say if you would prefer to unmute yourself, and ask a question in person, that's absolutely fine too. So just do that as well or raise your hand, if you'd prefer that too. So I'm gonna go in order, and I know we have, Anthony, correct me if I'm wrong, but we have a 20 minutes or so for questions, is that correct?

- [Anthony Priore] Yeah, just about that.

- Okay, cool, so we have 12 questions we should be able to get through those. So how did you become an Accessibility engineer at TPGi? Well, first, I was running, at my previous company, which was at Scalock. I was in London at the time and I realized that we had a product, that we had users et cetera, but no one had ever thought of Accessibility. and I randomly came across Accessibility as part of the clients that I was working with, and I was trying to sell the product for Accessibility reasons and they asked me, "But is your product accessible?" And I was like, "I don't know." And that was the first thing that I was like, "Okay, we need to look into this." And it became my obsession a bit to make that company at the time, What3words, accessible, and so it was a two year long program that I ran for Accessibility in that company on top of my sales job just to work directly with the product team to make them more aware of Accessibility, and I stayed with them for a couple of years doing that and then I decided I actually wanted work in Accessibility full-time, and so that's when I started looking at the different opportunities, and I had done a bootcamp for coding, so I had some basics in code, and I wanted to to be an Accessibility engineer and Testing and I think that to in a way learn all of the technical parts of Accessibility and I think that I've achieved that by being here at TPGi, so that's basically how I became an Accessibility Engineer. Okay, so what is a Contrast ratio, and how do we figure it out? So yeah, great question. That's about colors, and so a Contrast ratio, so if you have element A on top of element B, the Contrast ratio is the difference in color between like element A and element B, and it has to be big enough so that people who are low vision for example, can see the difference between the two elements, because if you have low vision, and the Contrast ratio is very low, you might not see that there's an an element A over element B. You might just see element B altogether, for example. I'm just giving a very random example, but that is what contrast ratio is, and you figure it out by using the Color Contrast Analyzer Tool on the TPGi website. That's the one of the great tools that you can use. Okay, hold on. Okay, cool. To conduct automated and semi automated tests, I'm not sure I understand this question, I dunno if you wanna jump in, but to conduct automated and semi-automated tests, web Accessibility evaluation tools list contains 84 tools just to check compatibility to recap 2.1 guidelines, which ones would you advise and how many? I dunno if the person who asked that question wants to jump in and expand on that, because I'm not sure what the question is. Yeah, I'm gonna leave it there. If you wanna jump in later, that's fine, otherwise I'll keep going. So about resizes, could you explain a bit more about what Accessibility features I am looking in a reflow mode, and resize mode? You're not looking at Accessibility features. The only thing you're doing is you're resizing to those dimensions that I had on the slides earlier. For resize, you resize to that slide to those dimensions and then you zoom in to 100%. Don't forget that part, and when you do that, all of the content of what you're auditing should be visible. So sometimes what's gonna happen is you zoom into that and then half of the website is not visible, or the text overlaps over each other, or basically the content that you're seeing without all of these resizes is no longer visible on the page, so that's what you're looking out for. You wanna make sure that the content can be visible, and again this is for low vision users who will use zoom, for example, or who will zoom in a lot to see the content. It needs to be accessible to them. It needs to be there for them, so that's what you're looking out for in there. Step four code to view the way page code, are you using Ctrl+ U or are you looking in the window? Yeah, so sorry, so the question was how do you look at the code when you're Testing? So I right click on the page, and then I go on inspect, and then I'm looking at the inspect section, and that allows me to find the code. That is definitely the way that I find the code. For decorative images, do you also need to add area hidden true? Interesting. No, because the alt attribute is already going to hide the element for screen reader users, so you do not need to add area hidden true to that. Sherry says, hi, I'm totally blind, I have passed my CPACC exam, how can I get started with a company in order to find a permanent position? What do you recommend for someone just starting out? Hi Sherry. Awesome, well done on on your CPACC exam. I passed it as well a few months ago, so well done. I would recommend, I mean this is what I did, and I essentially started just doing a lot of Accessibility stuff because I was passionate about it. I would recommend you get familiar with this Testing stuff. We have a lot of folks here at TPGi who are blind, and who are testers as well, so definitely, you can do something like that and it's actually very valuable to have blind people here working with us, because they'll be able to see things that we might not and who use screen readers much better than I can. So yeah, definitely I would say start practicing and start practicing how to audit if that's what you wanna do, or if you wanna do program management or something like that, then just start working where you are. Start just doing more of the work of Accessibility and just advocating for things. I think, in my experience, people respond very positively to it. There's a lot of education that is still to be done and so the more people do that, I think the better, so yeah, good luck. So Anita says, what tools you use to inspect test PDFs? Anita, I'm sorry, I don't test PDFs. I know we have people here at TPGi who are dedicated to Testing for PDFs. I am not, so I haven't done it before so I wouldn't be able to tell you. I dunno if Anthony wants to pick that up maybe and let you know later, but yeah, I'm not able to tell you. Sorry Anita.

- [Anthony Priore] We can certainly reach out afterwards, and get that question answered.

- Cool. Okay, so disability guidelines are different from each country. How do you overcome that challenge while doing Accessibility Testing? Yeah, hi Show. I'm sorry, I don't know if I'm pronouncing your name properly. Yeah, they are different, but most countries are based on WCAG. Not all I agree, but most of them are. So I would base it on WCAG guidelines really, if you're looking for some sort of base to go off from, I think that's your best bet. It is definitely the case for a lot of European countries and for the US and Canada, so I would definitely use WCAG as a guideline for that. How do you document and compile of the Testing results using a template document, et cetera? That's a great question. So we, here at TPGi, we have the ARC platform and that's how we use it, so we have, for us testers, it's essentially, we see an issue, we log it. We have a bunch of already pre-ready information that we can use and that's a way to give clients the feedback that they need; however, if you're gonna be Testing outside of TPGi, then something that you can do is, I mean sort of the quickest thing that comes to mind is using an Excel spreadsheet and then maybe list all of the WCAG criteria on one of the columns, and then go like pass or not passed, and then explain why they didn't pass if they didn't pass that particular criterion, so that's how I would do it on a simple Excel spreadsheet. How did you begin Accessibility Testing? What led you to your current role? Also, thank you so much for this presentation. Well thank you, anonymous. I think I already answered that question with the Accessibility Testing. I think just doing a lot of it before I was able to interview for the role, but yeah, I think I already answered most of that question earlier. For assistive technology Testing, do you only test with screen readers for blind persons, or do you also use speech recognition software for persons with activity impairments? Also, great question, Gary, thank you. I personally do not test with speech recognition software because a lot of the criterion on WCAG, so we are Testing all of the WCAG criteria and the WCAG criteria, if it passes, which we can see in the code, would apply to a speech recognition software user. So for example, I'll give you a very quick example, the 253, which basically means that if an interactive element on the page says, the example we were talking about with Twitter and Facebook earlier, if it says Twitter on the website, but the software is reading out, or the screen reader in this case, but let me circle back to that, is reading out the other, so not Facebook, but yeah, Facebook, but it says Twitter, that's gonna be an issue, right? But it's also gonna be an issue for a speech recognition software, because the user of a speech recognition software is gonna say Twitter because they're seeing Twitter, but actually the name of that button is gonna be Facebook, so it won't work, it won't recognize it. So we are Testing for those scenarios, but I am not personally using a speech recognition software, although I have to say I would love to learn to test with a speech recognition software as well. I just don't have the device on me, and yeah, I don't think everyone has it or everyone can have it as a tester. Can you set priority of Accessibility related issues? Oh, Shah, thank you. That's a great question and I would love to spend more time on that and, and I think I could speak for hours on that. I only have seven minutes, but yes, definitely I think really what you wanna thank here of priorities is what is making this not usable for some users and that should be the absolute priority, right? So something that is not accessible with keyboard or the example I just gave of a button that's visually something, but announced that something else that's also gonna make it unusable for some users. I think that should have priority over things like an image, for example, not having an alternative text of things like this or actually, well it really depends on in that example, because if it's a very important piece of image, it should have alternative texts, otherwise that information might make it unusable for the screen reader user, so it really depends on the cases, but I would say the utmost priority is thinking of fixing first all of the issues that make the product unusable for all users, any user of any demographic, so that's how I would prioritize, and then go down that ladder. What Testing can a new Accessibility professional do with the TPGi platform to get started? Specifically I know that there are TPGi tools and resources, but I am new to the field and I need to learn how to do automated Testing as an offering to my clients. Cool. That is great. I mean I think Anthony, you might be able to answer that better than I can, because I'm not actually selling the TPGi tools, but I would definitely recommend that you look at the Color Contrast Analyzer. I use it all the time, and then there's the arc plugin as well that allows you to automatically scan a page, and it gives you things like for example, this image doesn't have an alternative text, so things like that that can be automatically detected. So yeah, I'll let Anthony follow up on that. I know you're marked as anonymous, so if you wanna know more maybe message Anthony about this. Having said that, I do think that manual Testing is important. You're not gonna be able to see, there's something like 30%, if I'm not wrong, of Accessibility issues that you were able to detect with automated Testing, so it's very important that on top of automated Testing, you also do or you also have a way of manually Testing for Accessibility issues. Marisela asks, I've been wondering about Testing with real users, what are your thoughts about it, and have you ever done it? Yes, absolutely. Thank you for that great question, Marisela, yes, for me, it's an absolute must part of the process, because as much as I am an expert at WCAG and I know a lot of the ins and outs of WCAG, and I have experience using screen readers and other tools, it's never gonna replace the lived experience of a user on your product, right, on a real user on your product, and so I think that is, if I was not as, cause right now I'm Testing for clients, but if I was the client themselves, I would make sure that on top of the auditing, I would also be doing Testing with real users. There's great companies out there doing that, like Fable. I don't know if you've heard of them, but even more, and yes, I have done it before. I've done it before with my previous company, What3words that I mentioned. So a way of, actually at first my CEO and CPO, they were very against making any changes, and the answer I got was like, "Oh, we're not that bad in Accessibility." And so the way that I convinced them, which obviously wasn't true by the way, but the way I convinced them to really look at Accessibility in detail was to essentially do Testing and I did Testing and I showed them a screen reader user struggling big time to do any actions on our app, and that's when he was like, "Oh wow, we do have a lot of work to do." So it definitely has a huge impact on people and on companies, and I would recommend, yeah, taking Accessibility Testing with users, taking it seriously. Yeah. Cool, I'm gonna try to, I only have like three minutes. When Testing, how in depth do you usually go meaning a certain number of webpages outside of the pages. I work for large universities, so Testing becomes very time consuming, especially when going through every single page. Yeah, yeah, I mean if it's just you Testing, that's a big job. Usually, we have a team, a huge, entire team's Testing for the whole page. I think usually what we do is we separate it into different components, so small parts of that page and then we test like that. I would recommend doing that, because otherwise it just becomes heavy, and then also, when you're working with developers kind of going like, "This is a test sample of something I've audited, but you need to be looking at the same things everywhere else," because maybe you're not able to test the entire website, so just kind of find patterns and talk to your developers about the patterns that need to be fixed. How do you do mobile Testing Accessibility? That is a very wide question, but essentially just the same thing, just not looking at the code, so I'm Testing keyboard. I'm Testing orientation. I'm Testing resizes. I'm Testing colors. I'm just not able to see the code, and so I'm just relying on everything that I'm hearing basically. What versions of JAWS do you recommend to use? Yeah, I don't know the answer to that. I'm using the latest one, because that's what we get as testers, but I don't know, I don't know if maybe Anthony can answer that later better than me. What's the best tools you recommend to test? Do you mean automated test, and if so, I already answered that, but otherwise I'm not quite sure what that question means. Is there any tools which provide code level issues, and assistive text issues while scanning entire page? Yeah, so that's the automated test I was mentioning earlier. Again, they're really great tools, but I think, well there's the ARC Toolkit, and then there's something like, I think Wave I think it's called, and there's this Accessibility Insights as well from Microsoft and so on, but they only detect about 30% of issues, so just wanna reiterate that. Are there any language specific requirements we should consider when Testing? For example, if we're Testing in Spanish or Chinese? Yeah, you can change, definitely in the code, you should check that the language of the page is being determined in the code, because that's gonna determine how the screen reader is reading the content of that page, so yeah, that is definitely something to look out for as well. If you could only test one screen reader, which would it be? Interesting. I mean, I usually always test with JAWS and NVDA, so I guess, I don't know, but that's my job. I'm a tester so I'm meant to be doing both, so yeah, I don't know. When conducting web Accessibility Testing, do you take into account individuals with physio social disabilities or does it depend on client requests and target users? Yeah, so we are Testing based on the WCAG guidelines and the WCAG guidelines are meant to, taking everyone into consideration, so that is basically the work that I'm doing. If the client wants to do user Testing with people with disabilities of a different variety of disabilities, that is, I personally highly recommend that, that is great, but the Testing that we do is based on WCAG. What should be used for a logo, an image or an SBG? Not quite sure what that question means. Sorry, Marty, How do you recommend finding opportunities to help gain a better understanding of performing Accessibility audits? Would volunteer audits be helpful for beginners to get started? Yeah, I mean, yeah, if you have people who want you to volunteer, definitely I would just go open a page and just audit it, and take that spreadsheet, and then put all the WCAG criteria there, and just kind of audit and be like, I'm gonna audit this half a page today, and I'm gonna see what issues I find and read WCAG a lot, and kind of read examples and the documentation to guide you on what is a failure and what is not a failure. How do you get to the dimensions reflow resize box to test? That's a great question. So you're gonna go on the inspect section, hold on, I'm just gonna stop sharing. You're gonna go into the inspect section of that, and then you're gonna go onto, there's a little arrow at the top left of your inspect part of the website, and then there's one to the right of it that says toggle device toolbar, so you wanna select that, and that's when you're gonna have the different dimensions available to you. Can you address Accessibility of relays? I don't have time to address Accessibility of relays, but usually that's a no-go, and everyone who works in Accessibility will usually say, don't use Accessibility of relays please, because they bring more issues than they fix. So that's kind of the big industry understanding, but still a lot of companies use them, but that would be kind of the recommendation if I was talking to a developer or a team. A speech recognition software user using screen reader does not test for speech control. It's a false practice. Okay, thank you Gary. I'll take that and look into it a bit more personally. I don't, yeah, but thank you for that feedback. Is it possible where we import all site map URL and no Accessibility related issues of entire website should be reported? Is it possible where we import all site map? Sorry, I don't understand that question. When conducting web Accessibility Testing, do you take into account individuals with physical? Okay, I think I already answered that. That's a repeated one. Should you test on Mac or PC, or is one sufficient? Yeah, I usually test on PC because I don't have a MAC device. I know one of my colleagues has a Mac, and so she will test on one or the other. I think it depends on the agreement with the client on that. Certification related to Accessibility tester, will you please recommend? There are two that I recommend. There's a CPACC exam, which I've taken already, and there's also the WAS Exam, which is a bit more technical and definitely recommend thinking about that as well at some point if you're interested in doing Testing full-time. And I think that is it, all right. 35 questions answered, awesome.

- [Anthony Priore] Awesome job, Gigi. Thank you so much, and thank you all for attending, and for your amazing questions. Gigi, I don't know if you have anything you wanna say to follow up, but otherwise we can send everyone on their way.

- Yeah, thank you so much everyone for attending and all of your very insightful questions, and for the feedback as well. Yeah, it's been a pleasure to meet you all, and thanks for participating, and if you have any questions, let me or Anthony know.

- [Anthony Priore] Yeah, and for those who didn't get their questions answered, we will certainly be following up after the session. So thank you all and thank you Gigi so much. Awesome job. Everyone have a great rest of your day. Bye now.