- [Aaron] Introduce me and all.

- [Stefani] Thank you for joining us today. We'll begin momentarily.

- Hi, everyone. We'll start in a sec.

- [Stefani] Yep. Oh, we have a lot of people joining.

- That's great, exciting. Get some great questions.

- [Stefani] So good morning and good afternoon. My name's Stefani Cuschnir. I'm part of the business development team here at TPGi. We're gonna wait another minute or so and then we'll get started. Just give another second or two for everyone to join. I see a lot of people joining. I'll try to be very punctual on the nose. So thank you everyone for joining us today for "The Basics of Accessibility Testing" with Aaron Farber. I have a few housekeeping. Oh, can you not hear me? Are you guys hearing me okay? I see as anyone talking, I'm not able to hear in the chat. Okay, everyone can hear me. Sorry. Again, "The Basics of Accessibility Testing" with Aaron Farber. A few housekeeping items before we get started. This session is being recorded and we will email everyone the recording after the event. We have captions available, so feel free to use them as needed. We will have time for live Q&A. Please use the Q&A box and we will answer as many of the questions as we can at the end of the presentation. Lastly, I'd also like to mention if anyone needs any accessibility support, training, or usability testing, I will be sending out an email with a link to schedule a time to speak with one of our experts. With that, I will let Aaron get started and he can provide an introduction to himself.

- Hello, everyone. Welcome to "The Basics of Accessibility Testing" webinar. My name is Aaron Farber. I am senior accessibility platform consultant here at TPGi. Let me start by just talking a little bit about myself and my own journey in tech and accessibility. In 2016, I changed careers from public policy to technology, and I attended App Academy, it's a coding bootcamp. Proud, proud attendee of App Academy, I recommend it. And from 2017 to 2019, following the the bootcamp, I ran an accessibility development and testing shop. And it was really focused on small businesses, the kind that used, you know, WordPress and Shopify. And then from, you know, following that, 2019, I started working for TPGi, and I began as an accessibility engineer. And in that role, I mainly do manual accessibility reviews. Then in 2021, I had a new assignment from TPGi. I was embedded with a large tech company, working on their internal accessibility program. And this past year, I've been accessibility platform consultant here at TPGi. And what does that mean? So, well, in this role, primarily supporting the ARC Empowerment Program. TPGi's ARC Platform provides the tools and resources to plan, manage, and execute every area of an online accessibility program. And, you know, there's so many tips and techniques and suggested best practices to running accessibility program that it can be difficult to know where to start. So the ARC Empowerment Program, you know, it removes stresses about what your organization is not doing, and it focuses on the most important steps in growing an accessibility program. So in 90 or 120 days, you know, organizations, they gain a repeatable process for testing accessibility, which they can apply to every online experience that they deliver, you know, currently and into the future. And, you know, that all starts with an understanding of the foundational concepts of web accessibility. So today's session is not about, you know, ARC so much, but it's about, again, the foundations to understand about accessibility testing. And that's something that we've really learned is in the ARC Empowerment Program is the key is having that, you know, those understandings before you, you know, become master accessibility and work with all the different, you know, tools and resources within the platform. So let's look at the foundational concepts we'll be going today. We're gonna be moving quick and, you know, there is so many nuances to accessibility testing that, you know, that's where a resource like the ARC Platform is so helpful and we'll kind of talk about that more later. So first of all, you know, first, we're gonna go over an overview, why accessibility matters, you know, understanding accessibility guidelines. Then we'll move to creating a test plan, the steps to take before performing an accessibility review. Then we'll go over the topic of focus, which is, you know, could be rephrased kind of as keyboard testing. Then we'll talk about how webpages expose semantics to assistive technologies. Then we'll talk about the structure of a webpage and again, how that's exposed to assistive technology. And then we'll talk about the role of ARIA and kind of help you to understand what that represents and when to, you know, how to identify elements on a page that perhaps require ARIA. And then we'll talk about color contrast testing. And we'll lastly talk about, you know, complex interactions, you know, the kind that do not fit neatly into perhaps an established UI pattern. And we'll talk about, you know, how your organizations, you know, can take on those kind of, you know, more challenging, more sophisticated accessibility issues. So that said, you know, first of all, on, you know, this slide, it's human dignity is the same for all human beings. And, you know, that's fundamentally the basis for accessibility is that, you know, all people deserve that ability to define themselves. And so on this slide is a picture from a magic illusion show from a person named Derek DelGaudio. It's on Hulu, actually, and it's worth a watch. And in the illusion, basically, each person start, I won't spoil it, but it starts with each person selects a card that says, I am a life coach, I am a lightning rod. I am an oracle, a loan officer. And, you know, people define themselves and that connected with me in terms of how to perceive accessibility. Now, without accessibility, you know, disabled people are excluded from public and private life. In this image here, we see a man next to a racing car with the hood up. You know, the engine is smoking and he's watching a race pass by. And that's what it is when we, you know, again, when we're not providing an accessible environment. You know, people cannot participate in the economy. Now, as you are conducting accessibility testing, you know, it's not simply about HTML and, you know, code, it's a mindset to have. And that is accessibility is about ensuring the same experience for all people. And that's a mindset to carry through, you know, again, not just to your own website, but just everything that your organization does. And the origins of, you know, web accessibility, online accessibility, you know, they don't pertain to websites, you know, they pertain to ATMs, actually. So again, it's something to view across your environment. So, you know, when you first start to do accessibility testing, you know, an organization must first define the guidelines that they are testing against. And there are two options. There is, number one, the Web Content Accessibility Guidelines, WCAG, or you can define your own internal accessibility guidelines. So we're gonna talk about these two options. So WCAG is defined broadly to cover a wide range of content. You know, the WCAG authors understood that they could not foresee all the kinds of web content that would be created. Now, when a court finds a website or a web application is inaccessible, the remedy is to conform to WCAG Level AA. So it's almost always recommended to audit applications against WCAG Level AA. Now let's understand, you know, AA, let's understand the WCAG levels in technical terms. So to make an application accessible, you know, requires, on a practical level, one of two things, you know, either requires, you know, resources and changes to a site's codebase or it requires changes to a site's visual appearance. So Level A conformance with WCAG does not require one or two. So to conform to Level A, you don't need significant resources or, you know, custom, you know, like custom engineering or to necessarily make changes to your site's appearance. That's why something like adding alternative text, right? That doesn't change the site's visual appearance and it's a functionality built into native HTML. Now AA, which requires one or two, so it requires either resources and changes to a codebase or changing a site's visual appearance. So, you know, color contrast may be easy to change, you know, it's simply just changing the color of a background perhaps. But that is a change to a page's visual appearance, so it's Level AA. And Level AAA, it requires one and two. So that requires to conform to AAA means significant resources and changes to a site's visual appearance. So an example of like AAA is, you know, sites could have a sign language interpreter for videos. So you can see how that is something that would take effort and also would change how the page appears. Now, let's talk about the WCAG levels in human terms. So not in technical terms, what it takes to make something conform to WCAG, but what do these levels actually represent to the end user? And that, of course, is what is most important. Level A, it ensures the most basic level of access for disabled people. It doesn't really provide an equivalent user experience. It means that they can access the functionality in some sense. So I would think of that as something of like kind of providing a phone number rather than them being able to use a website and do an activity at any time of day that suits them. You know, because a phone has like, you know, business hours. Level AA ensures disabled people do not encounter significant barriers and it provides a mostly equivalent user experience. And that is why a Level AA is generally set as the conformance target, you know, when, you know, the legal system is determining a remedy. Level AAA is not about an equivalent experience, it enhances the user experience for disabled people. It provides accommodations for people that may even have multiple disabilities. You know, someone could be, you know, not only visually impaired, but they could also be deaf. And so, you know, that's gonna require different kinds of accommodations. Now, after you decide which conform, you know, which level of WCAG to conform to, if you are using WCAG, you must select the version of WCAG. So currently, you know, WCAG 2.0 was published in December, 2008. It's a long time ago now. And version 2.1 was published in June, 2018. And for TPGi, and most of our manual reviews, we're using version 2.1. And WCAG version 2.2 is in the draft stage. It's scheduled to be finalized in early 2023. And each version builds upon past versions. In other words, to conform to 2.1, you must conform also to 2.0. So another way to phrase that is it's backwards compatible. And you know, with WCAG 3 is an overhaul. That release as far off, they say 2026 maybe. And I tell people, you know, I get asked about, you know, just treat that like, not a, you know, like Dr. Dre's "Detox" or George R. R. Martin's like "Game of Thrones" sequel. It's something we're kind of I'm excited to see, but it's not really clear when it's gonna come about. And, you know, there'll probably gonna be delays. So it's not something to really think about at this point. Now, WCAG has grown in size, you know, from 2.0 to 2.1 to 2.2. Each WCAG version, WCAG 2 version has added success criteria mainly to clarify ambiguities or obvious gaps in past versions, you know, and a very large gap between 2008 and 2018 was, you know, mobile devices, you know? So that is a lot of success criteria were added to cover mobile devices. So here, we look and we can see that 2.0 had in total, or I guess I should say between Level A and Level AA, there were 38 success criteria for version 2.0. Version 2.1 became 50 success criteria. And version 2.2, again, scheduled be finalized next year, has 57 success criteria. So we can see WCAG is, you know, it's growing in, you know, complexity in some sense that there are more discrete tests to apply to a page. And, you know, that does present challenges. Now, internal accessibility guidelines, you know, they're increasingly popular option for large organizations, which have their own internal accessibility teams. Now, creating internal accessibility guidelines, you know, requires a level of an internal accessibility expertise and the substantial time and effort to create them. Now, internal guidelines cannot have gaps when compared with WCAG. So you can't use, like, internal guidelines and say, "Oh, well, in our guidelines, we don't serve a particular user group." That's not acceptable for your own internal guidelines. So a site which conforms to our internal accessibility guidelines must also conform to WCAG. So let's consider the implications of that. Like, again, if you're a larger organization. Well, you know, the benefits to using internal accessibility guidelines is that you can use them to either simplify WCAG, then, you know, it's like it's growing in size, 57 tests next year. Or you can use it, you know, internal guidelines to expand upon WCAG. So let's look at some examples. So, you know, here, and again, you know, when I was a part of this larger tech company, we were kind of creating internal accessibility guidelines. And so we got to see kind of some of these benefits and drawbacks. So when you're simplifying WCAG, the approach that I see is that with internal guidelines is people break the WCAG success criteria into more distinct tests. This is more comprehensible perhaps, and it allows like for greater templating of remediation solutions, and there's less reinventing the wheel. So let's look at an example here. WCAG success criteria 3.3.2 labels or instructions. You know, it covers, you know, a number of things relating to form labels, you know, forms. And again, you know, these WCAG guidelines are written broad enough that they can be applied to a lot of different contexts online. So instead, with internal guidelines, it can be broken down into a set of tests to apply to a page. So they might say, "Oh, for guideline 3A, form controls must have visual text labels unless there are nearby controls which indicate their purpose." And this is all, really, these are techniques that are suggested by WCAG, but they can be kind of made into tests. Or 3B, form controls use placeholder text to provide additional hints or suggested values. And not to restate, not for the primary visual label. 3C could be groups of related form controls, right? Like, a Social Security number where you're, you know, sometimes you see that where you have to add your, it has three different form fields for it. Groups of related form controls must be enclosed in a box, you know, surrounded by a border to visually indicate that the controls worked. So that's kind of how you could simplify WCAG. And you can see how those tests may be easier to apply for someone that, you know, to a tester that has less expertise with accessibility. Another way that we can use internal guidelines is to expand upon WCAG. And I've seen a number of retailers do this. And what they do is they add best practices to WCAG. So here's some examples from companies that are using internal accessibility guidelines, is they say interactive controls, you know, buttons, links, may not use the browser's default visual focus indicator, and we'll talk more about focus later. We saw that, it's an upcoming topic, or each control must have a tough touch target greater than 30 CSS pixels. So that's actually a AAA success criteria. And so they're saying, "Well, we wanna take some of AAA, but we don't want to conform to all of AAA." Another example might be, you know, icon based controls used visually hidden text to provide name rather than an ARIA label. And the thinking there is that visually hidden text is, I believe, is more likely to be properly translated by the browser if someone uses auto-translation services. I believe that was the thinking at the time. Now as I said, you know, WCAG 2.1 Level AA, that's the recommended accessibility standard to apply for your testing for most organizations. And when an organization's accessibility program grows to maturity, they are then prepared to create internal accessibility guidelines. And so on the slide, we have a picture of a seed growing into a full plant in a series of steps. And that's really kind of the essence of doing accessibility testing, having an accessibility program in your organization, is that it grows in maturity and complexity and you're able to do more things like that, you know, kind of, you know, defining your own standards and processes. Okay, now, you know, in the ARC Platform, you know, it recognizes that there is this evolution from using something like WCAG. So, you know, in ARC, you know, it empowers organizations to use their existing standards and testing tools to grow from, I should say, it empowers organizations to grow from using their existing standards and testing tools to creating their own custom accessibility testing process. So the ARC Platform provides out-of-the-box accessibility rules engines like ARC and the open source rules set Axe for accessibility standards, but organizations may also create their own standards and configure and use their own custom accessibility rule set. So once a standard is set, once you set, you know, the standard that you are testing against, your next step is to create an accessibility test plan for each of your online experiences. And so we'll look at what it takes to create a test plan here. And there's a lot that can be said about a test plan. So we're gonna move quick. You know, being deliberate in how you plan your accessibility work is, you know, fundamental to ensuring that everyone understands their role in testing for accessibility. So again, we'll move quick and, you know, if we have more questions about test plan, we can, you know, kind of talk about that at the end here. But, you know, what you need to get started testing is a couple of things. First, the accessibility standard, you need your testing tools, assistive technologies that you'll use to test the page, your test plan, and you'll need a system to record results for both automated and manual testing. And lastly, you'll need a knowledge base with resources to, I call it a three-step process, you know, to understand, test, and solve. So to understand an accessibility issue, to test for the accessibility issue, and then solve for an issue. And so again, a knowledge base can provide those resources. Now, you know, fundamentally, you know, my, and I think TPGi's testing philosophy, is that the more tests are built to resemble the way your team builds applications, the more confident tests will give you and the easier it is to collaborate on accessibility. And what does that really mean? Well, you know, when you are creating your test plan, first thing, you know, is about scoping, is to select a representative sample of your application. It's not feasible to test every page, every widget on your application. And more than that, that's not really how most organizations develop applications anymore, right? It's largely component-based testing. They use either their own component library or, you know, something like Bootstrap or, you know, if you're using, you know, Shopify, you know, each of their, you know, sites, their templates comes with a set of template components you can use. So a test plan first breaks a website/web application into components and you know, in other words, into smaller chunks of code. And it focuses on the most high impact user journeys. Again, you know, the reason why, you know, someone may have an issue with the site is not the number of WCAG violations necessarily, but it's that they can't access a critical functionality on the site. So we wanna cover those functionalities, those user paths within an application. So examples of components include template components, you know, navigation, bar, footer, recurring components, you know, it could be like tab panels and other widgets that you reuse across your site, or page-specific components. So those could be like, you know, user journeys, like a form to complete, you know, to register for some service. And, you know, component-based testing, you know, testing your site in this manner, you know, it facilitates communication and cross-collaboration. 'Cause for a very large sites, you know, there's different teams working on different parts of the site. And when accessibility testing results are scoped to these components, it's much easier to delegate work. And you can set accessibility testing at a pace that suits your organization, right? 'Cause we're gonna do a certain number of components per week or we have a certain number of hours for them. Now, when you are defining a component in your test plan, it's important to understand, first of all, that testing a component includes testing it at its responsive breakpoints and its various application states. And for each component in your test plan, you know, it's recommended to provide a name, you know, an ID, you know, a screenshot, the steps to reach the components, you know, especially if it's deep within a user journey, where, you know, certain, you know, steps have to be taken, but certain form values may have to be entered to trigger the interaction, to trigger the component to appear. And, you know, the component should also state what's specifically included in the component or not included in the component. And lastly, I recommend, and this can be hard to determine, but a component should state the estimated level of effort to test it. And this is important for you to be able to understand how much time kind of needs to be allocated towards testing for accessibility. And over time, it allows you to kind of evaluate your own accessibility maturity. Is your testing, your QA teams, are they turning around applications faster? Are there opportunities for automation? And that's kind of, again, like, wide level of effort is a helpful thing to note, even if it is just an estimation. Now, your first component in your test plan is common issues. And common issues, global issues, they apply to the entire site. And a common issues component, it saves time. So you don't have to flag the same element, the same issue on multiple pages multiple times. So an example might be, right, is that a site could lack a page title, right? A page title is the name of the page that appears in a browser tab, you know. So that might be lacking across the whole site. It's not necessary to note it for each individual page. And while it's not always possible, in your test plan, the component should be order organized. That is the order of the component in your test plan should be based on their importance to the application 'cause as I said, you know, manual testing is time consuming. So, you know, it's reasonable to kind of go through it and you know, again, to your most important components first, which is generally, it'll your template components, right? Because, you know, the nav bar, the footer, regardless of what page of the site a person is on, whichever user, you know, functionality they are accessing within the application, they're going to encounter those components. So, you know, that's why they're highest priority. And it makes it, again, easier to over time delegate testing to people on your team because you understand, you know, what is the priority just to go through the test plan from start to end. Now, here's an example. I was talking about, you know, when we define a component, we have to test it at the different responsive break points and at the various application states. So, you know, on this slide we see tpgi.com screenshots of the navigation bar in the desktop layout and also in the mobile layout. And we can see in desktop layout that the nav bar has a search field, it has a set of links, or I guess I should say kind of, you know, expandable collapsible fly-out menus for ARC Platform, Solutions, Resources, About, Blog and Get Started. But then it has another kind of navigation region that it does breadcrumb navigation. And then for the mobile layout, we see that the fly-out menus I described have been collapsed into a hamburger menu. You know, the classic three stripes, right? The bun, the patty, and the other bun, right? And the breadcrumbs have become what appears kind of almost like an accordion tab panel. They're now stacked vertically. Now, we see the tgpi.com navigation page in its expanded state. And so on this, you know, we have screenshots here in the desktop layout, the fly-out menus being expanded. And in the mobile layout, we have the navigation becomes kind of a side menu, you know, which expands out from the side of the page, from the right side of the web browser page. And, you know, the point is to these screenshots is to indicate that if we're testing a navigation region, you know, all of this is in scope. And I find it's important to communicate to testers that, you know, they will be testing at these different break points. And these are examples of things that you may wish to note in your test plan as, you know, like, again, of the various application's tests like, oh, at responsive break points, it has a totally different UI that needs to be tested. And now, you know, when a component becomes too large, I think, you know, from those screenshots, it appears like that navigation bar has a lot of functionality, it has even a search field. Well, when a component becomes too large, you know, just break the component into multiple components. So, you know, again, this is the navigation bar here was very large. So I'd actually, if I were creating a test plan for tpgi.com, I would create it as two components, as a primary navigation and as a secondary navigation. And again, this is to make the testing into these chunks that are more manageable. Now, when you're testing the component, you know, WCAG 2.1 Level AA is made up of 50 accessibility guidelines as we noted. You know, so you'll start by testing the component and just indicating the guidelines which are not applicable. And to make testing more efficient, you'll group related accessibility guidelines in your testing so that you're testing similar things at once, not, you know, testing, you know, going back and kind of retesting things if you were to just go through WCAG, like all of Level A and then all of Level AA. I don't recommend doing that. I don't recommend doing Level A and then Level AA. I recommend, again, grouping them by their different area. And that's kind of how this presentation is organized today. So now, as I've kind of noted, you know, manual testing, there's a lot of nuances and the web is vast. You know, people have a lot of different websites and web applications, you know, it's really helpful to support testing with a knowledge base. And this is again, you know, today it's not about ARC, but that's a great advantage to using the ARC Platform, is it provides, you know, a very robust and comprehensive knowledge base. And a knowledge base for accessibility testing should consist of foundational role-based trainings. So that might be for people that produce PDFs and all these other different kinds of content that are gonna be hosted on your website, potentially. The manual testing methodologies. And by that I mean, you know, step-by-step instructions on how to carry out these tests for each guideline. You know, it's not reasonable or efficient for testers to go to W3C's website, review the creator's WCAG, and review the documentation, you know, and kind of parse that and determine how to test. Another, you know, part of a knowledge base is, you know, is really automated testing and template solutions. And I want those together because, you know, the main strength, to me, of automated testing is that it is identifying common issues, which have, you know, templated solutions. So again, there's less reinventing the wheel. And lastly is recommended design patterns. A knowledge base has to describe actually how to fix these accessibility issues, how to retest them, and validate them. Okay, so now let's really move on to, you know, we've gone through kind of these steps of preparing for an accessibility test. Now let's actually talk about the steps of conducting an accessibility test starting with focus. So focus is, you know, understanding focus is the foundation for, or, you know, understanding focus and performing keyboard testing is the foundation for supporting assistive technology. Keyboard testing does not require specialized knowledge or a development background. So for, you know, people in, you know, on this webinar, you know, anyone at your organization can do this and I recommend, you know, doing it yourself if you are rolling out applications, just each person has, you know, accessibility is not the responsibility of a single person, you know? It can't be. And so keyboard focus, focus is the control on the screen that is currently receiving input from the keyboard. So people navigate the web, or in other words, they control which elements has focus by using the Tab key. You know, you press Tab to move to the next focusable element and you can press Shift + Tab. So at the same time, Shift and Tab, to move to the previous element. And so again, for keyboard testing, just simply tabbing through your site is really effective. And now another thing to keep, you know, in mind when you are doing focus keyboard testing is focus order. So focus order is the order of focusable elements on the page. Focus order is determined by the order of the elements in the DOM, which is the Document Object Model. It's essentially when a webpage loads, you know, the browser, you know, constructs this tree structure connecting the different HTML nodes on the page. This is, you know, we colloquially refer to this sometimes as the page's natural focus order, right? Because we are, you know, it's being coming from the natural order of the elements in the DOM. Now, a correct or logical focus order follows the visual order of elements on the page. Now, some webpages may have multiple ways one could visually understand the page. So, you know, it's not always, you know, there could be different ways to interpret, you know, what's a logical focus order. But for most sites, you know, it's top to bottom and left to right, you know, that's the order in which we're reading the content. Now, some advanced information about focus order is sites may override the page's natural focus order. You can apply a positive tabindex attribute to an HTML element to explicitly set that element's position in the focus order. So you could, if you apply, you know, like tabindex of one, well, then it will be the first focusable elements on the page, overriding the page's, you know, natural order. A negative tabindex attribute, when it's applied, removes an element from the focus order. So, you know, you might do that if, for some reason, you don't want an element to receive focus. Another way that we affect focus order other than the natural focus order is we use JavaScript. So the DOM, the browser's building its DOM so that JavaScript can select these different nodes and move them around on the page. Now, that's the role of JavaScript in web. So JavaScript can also be used to move focus to a particular location in the page. And, you know, and another significant point to bring up with focus is that when there is a change in focus, that triggers an announcement to assistive technology in most cases. So that can be a way to make people aware of a change on the page. I'll talk more about that. Now, you can also visualize page's focus order. ARC Toolkit is a free Chrome extension. It's available in the Chrome extension marketplace. It allows you to run, you know, the ARC rules, you know, automated accessibility rules engine on your webpage. It also provides these guided testing tools such as a tab order visualizer. So here, you see we have a screenshot of tpgi.com and there are arrows and numbers for each focusable element. So, you know, the brand logo at the top of site is number one. And then the first link in the nav bar is number two. And so I like this feature within our toolkit because it's very good for accessibility testing. It makes it easy to share issues regarding focus order. 'Cause honestly, like, you know, writing it in actual, like, pros and it can be very time consuming to say, "Oh, and then the page goes from here to there." Again, this tool allows you to just easily visualize it, can be very efficient. Now, when you are keyboard testing, these are the set of WCAG success criteria to kind of have together at once. And you know, I hope, you know, we're gonna go through some of these things fast because I want to make sure that we have time for a little bit of questions at the end. This slide deck is also just a resource for people attending the webinar and something that I hope you'll use for future reference. So key questions to have when you're doing keyboard testing is for one is, is all site functionality accessible via keyboard? Is it possible to skip repeated content like the navigation region? And you may have seen skip links online. Is the page's focus order logical? Does it follow how one would expect to interact with a page? Is it always possible to visually determine the element that is currently focused? Is the visual indicator easily perceivable? Are there non-interactive elements in the page's focus order? Because, right, if an element's not interactive, why should it be able to receive keyboard input, you know? So it has no functionality for the keyboard. Dialogs have a lot of elaborate focus management requirements. You know, dialogs have to contain focus. When a dialog appears, we have to move keyboard focus to the dialog. We have to set the user from what they were doing to the dialog. And if you're unfamiliar with the word dialog, I realize it's, you know, it's a pop-up on the page that's requiring the user to interact with the pop-up's content before they can return to their activity on the page. So return to the activity is the key phrasing here, right? Because when the dialog closes, we have to return focus to what they were previously doing to the element that was previously focused. Now onto semantics, how webpages expose semantics to assistive technologies. And these are kind of, you know, this is really kind of the start of screen reader testing what we're talking about here. You know, and to me, screen reader testing, you know, is aided substantially with a basic understanding of HTML, CSS and JavaScript. You know, HTML being a page's structure, CSS being the styling, the JavaScript being the functionality, the movements of elements on the page. So HTML elements have roles. And the semantics of an element is not apparent from its visual appearance. A screen reader does not communicate information based on an element's visual appearance. So to understand an element's semantics, well, you could use assistive technologies or you can use developer tools to look under the hood, you know, at the underlying code to understand the semantics of an element. And again, HTML elements, they have built-in semantics. So when you use the correct HTML element, you're getting that semantics for free from the browser. When we create webpages as they're kind of intended to be created with HTML, we get a lot of accessibility for free. And that's why, you know, it's always advisable to use native HTML when it is available. But we are able to override the semantics of an element using ARIA, but then it's not advisable. Now, understanding assistive technology. Assistive technologies, you know, they don't actually interact directly with the webpage, you know. I should say screen readers is, you know, they interact with the browser's accessibility API. That is the semantics that the browser is exposing to the screen reader. Accessibility APIs, they strip down the elements which do not have meaningful semantics, you know, such as CSS, to provide a lightweight version of the page. It's sometimes called the accessibility DOM or the accessibility tree. And in the webinar, following the webinar, I'm gonna send a bookmarklet, which will allow you to kind of create a stripped down version of the page. So you'll be able to just kind of see how your page would kind of look to a screen reader user in a sense. So keep an eye out for that. Now, name, role, and value. Each interactive element has a name that is the purpose of the element. And that comes from the text within the control or from an ARIA label or an association with another element on the page. And there's the role, that's the role of the element. And the value, you know, and the role would be like a button or a link or something. And the value is the current value of the control. So when you are testing a site and you are reviewing an interactive element, your mindset should always be, does it provide a name? Does it provide a role? Does it correctly convey its value, its current value? So here on this screenshot of tpgi.com, we have Chrome developer tools open. We have selected the Get Started disclosure control, the expandable collapsible control in the tpgi.com nav bar. And you see here that we have the Chrome accessibility pane. So you can select Accessibility, it's kind of by the CSS inspector. And you can view the actual semantics for an element. And I should state also here that, you know, this is not, like, gospel, right? Like, the screen reader, those technologies is the ultimate source of truth. So even if the browser says, "Hey, we're exposing this information." Well, how is the screen reader actually announcing the element? Now, usually, those things I find, you know, they're very, you know, similar. You know, they're generally the same, but especially for complex elements, there could be substantial difference between what the browsers kind of thinking it's exposing and what the screen reader may announce. So, you know, whenever anybody is, you know, conducting accessibility testing, I always recommend just becoming familiar with Chrome developer tools. Div and span, these are just generic elements, which don't convey meaningful semantics. Moving on here. Structure of page, you know, so JAWS, you know, when you're doing, you know, screen reader testing, you know, again, we talked about you need your set of assistive technologies to take on basic, you know, accessibility testing. So, you know, JAWS is paid for, but it has a free 40-minute mode, which could be used. But, you know, when the 40-minute mode runs out, you have to reboot your machine, restart the machine, really, to use it for another 40 minutes. But again, for limited screen reader testing, 40 minutes could be, you know, more than enough time if you're just trying to get at the end to how a certain element is announced. Alternatively, you can use NVDA, it's a free screen reader for Windows and it has features that I think, they're particularly helpful to sighted testers unfamiliar with screen readers. Now, you know, screen readers definitely have a learning curve even for testing. An option is to use JAWS Inspect. It's a free screen reader testing tool, or I shouldn't say free, I should apologize, it's a licensed screen reader testing tool from TPGi. And it allows testers to easily generate a transcript of how JAWS would read the page. You can simply right-click the page and it will produce this transcript of JAWS reading it from top to bottom. And again, that can save a lot of time. And here, it also provides a speech viewer. You can actually use JAWS Inspect to navigate the site and produce this transcript, you know, following your navigation path. You know, I'm gonna kind of pass through these slides on how to configure NVDA, but if you are using NVDA for testing, these slides will be very helpful. So something definitely to refer to in the future. Another easy way, you know, again, you know, screeners have a learning curve, but even for someone that is not, you know, very adept at using screen readers, a very helpful aspect of using them can be that screen readers allow you to pull up, and this is actually most screen reader users, when they navigate the web, they generally navigate by headings or by pulling up a list of links on the page. So screen readers can produce a list of those elements on the page and you can simply pull them up. And it's a great way to test that each link on the page has, you know, comprehensible link name, because, you know, if the link text is not, you know, specific, you know, the screen reader user has to go to that element and read around its surrounding context to understand the link. And it's quite cumbersome, you know, and it prevents them from using these navigation shortcuts. And the same thing can be applied to the list of headings is it allows you to easily see the structure of headings on the page. And these are just the shortcuts for those controls. Now, ARIA. ARIA does not change the page functionality for any group of users other than screen reader users. You know, ARIA fills the gap in native HTML. So, you know, elements such as tab panels or progress bars, you know, those are not native HTML elements and they must be constructed using ARIA. So when you're going through your site and you see elements like that, your mindset should be, "Oh, I know that this probably requires ARIA because it's not an element, it's not a simple element." You know? And those kind of custom elements always should grab our attention most during testing. There's kind of the most room for error, right? And error in terms of, you know, the creation of the element. Now ARIA, the role of it is to bring sound from silence. That's what I say. So, you know, when an element has multiple states such as expanded or collapsed or, you know, an element triggers, you know, another part of the page to change, you know, that change is due to JavaScript. So without ARIA, you know, these JavaScript interactions, they don't trigger an announcement to assistive technology. So that's where ARIA comes into play. And so, you know, just even if, again, you know, you're using the screen reader and you're not particularly adept at it, you know, you can simply just use your site and see if actions are triggering an announcement. You know, and if they're not, then you know that's likely an issue. Like, if page contents is changing and there's no announcement, 'cause, you know, screen reader is not gonna be aware of the change. So here's an example here. So here, we have a Get Started expandable collapsible control. And you see, here's the announcement from NVDA is that when we first set focus to the control, it's announced as Get Started expanded link, right? So there's the name, there's the role, and there's the value, right? The current state. And then when it's toggled to expand it, it triggers this announcement that it's collapsed. I guess these are actually in the reverse order, but point still stands you see is that the interaction is triggering an announcement. So don't use ARIA unless you have to, as we've stated. We're gonna keep moving. And status notifications, things like that on the page, where, you know, it may not make sense to actually move focus to the elements. You know, there's no actual functionality there, it's just text. Again, those things have to be notified to screen reader users and that usually requires ARIA. Single page applications, you know, React, Angular, Ember, those kinds of things. You know, for those sites, developers have to recreate browser feedback, you know, such as a page title being announced or focus being set to a new page. So that's again something where ARIA can be used to convey those things. Now, the last thing that we'll talk about here is color contrast actually. And so we'll move quick here. Here's a set of guidelines. And the Color Contrast Analyzer, it's free from TPGi, it works at the operating system level. So you can select any two pixels on your screen and test them for color contrast. But a note about using this eyedropper tool to grab things on the page, the best practice is really to compare the color values explicitly set in CSS, if that's an option, right? Like, if it's an image, you know, there's no CSS, right? So your monitor's color profile, your screen calibration may result in eyedropper tools, not just from color contrast tool, but at Photoshop or any of these things. You know, they can affect the actual color reported. So, you know, one color combination may pass on one screen but not on another. And kind of your wheels are turned spinning, right? Like, automated color contrast testing, it's actually very difficult to do. There's a lot of background images, elements overlapping one another, images of text, infographics, all these things pose issues for automated color contrast testing. It's really something that has to be done manually. And lastly, for complex interactions, you know, these are things that, again, like, are not defined UI patterns. You need access to accessibility support and, you know, the ARC Platform provide, you can get a help desk subscription so that you can get access to an accessibility expert on demand for those kinds of questions. So, all right, now I am going to take on, we only have a few questions here, but I'm gonna view them real quick. Let me see. Oh, and my final thoughts, I guess, is, you know, above all just get started testing. You know, there's no better way to grow your understanding of accessibility. And you can use the ARC Platform, it has all these tools and resources in one place, but they are available online and they can be cobbled together. It's possible, but, you know, again, this is very, you know, time consuming and inefficient perhaps. So, okay, now questions, let's answer 'em. Let's see what we got here.

- [Stefani] Yeah, we have a couple questions, Aaron, and about two minutes left.

- Yeah, that's great. I think I can answer these in two minutes. So in color contrast testing, what are the top tools in your opinion? Well, look, I mean, Elizabeth is asking, and I guess I should move the questions on here, is if you use the hex code of a page that has opacity applied, your test will not be accurate. But if you use the eyedropper, you can choose the pixel and you may still not get an accurate color selection. Well, you know, color contrast does prevent, you know, does present difficulties in this sense, right? But, you know, generally, you know, it's not gonna be that much variation between browsers, I mean between screens. And another thing that I wanna keep in mind, you know, about color contrast testing is I am not an attorney but I have seen many accessibility complaints and lawsuits and settlements through the years. I have never seen one based on color contrast. Color contrast will almost never be an issue which prevents someone from accessing a site, maybe an annoyance, it may be an inconvenience, but it will not prevent them from accessing the site. So that's why I talk so much about screen readers and these other things that, you know, again, can really be critical barriers. According to WCAG, disabled buttons don't have to adhere to color contrast requirements. So if a disabled button qualifies as an inactive UI component, which it technically does, we don't have to make it accessible. Well, I mean, yeah, you don't have to, yeah, it doesn't have to conform, it doesn't have to have color contrast while it's in a disabled state. That is true. So that's good comment. That's good exception to the rule. Again, nuance of testing. Were there any changes in AAA over the versions? The chart only shows the number of As and AA, only talked about A and AA. Yes, we've added a lot more AAAs than we have for A and AAs. The AAAs can be kind of subjective. And since they're best practices and, you know, we're not basing legal claims on them. They've really added a lot of them through the years. So yeah, they've definitely grown that number much more so actually than the other categories. If you are limited in funds and time, what are the top three things you should be looking at when it comes to accessibility? Number one, keyboard testing. Number two, pulling up a list of links and headings on the page. And number three, looking at interactive elements on the page and seeing that they trigger an announcement to assistive tech, reflecting their current state. So again, keyboard testing, headings, links, and dynamic elements. That's my answer to that. Great, so thank you all for attending. We're gonna share this slide deck afterwards, as well as the recording.

- [Stefani] We do have a couple other questions, Aaron.

- Oh, okay. I didn't see them.

- [Stefani] Finish that, but we can either, you know, get back to people with the answers. I think it wasn't in the Q&A, it was in the chat. I think Greg asked-

- Oh, I see, okay. So let me take it, okay.

- [Stefani] To expand a little bit on what ARIA is and how to implement it.

- Oh, all right, well.

- [Stefani] But we could always save these and get back to.

- You know, I can hang out for a few more minutes and answer them, but also I'm concerned about excluding people who have other things to do. But I will answer them right now and then I will also provide the answers in an email afterwards. Does that sound good? You know, but I'll finish them. It's just a few questions so I think we might be able to get to it just in the next two or three minutes. Could you expand a little bit about what ARIA is and how to implement it? Well, you know, ARIA is really at the code level. So that's, again, something that, you know, generally, you know, developers are going to be implementing. And, you know, as I said, right, like we looked at that example of an element expanding or collapsing. So if you think about it, right, like, the ARIA value also has to toggle. So that means you have to use JavaScript, you have to use code to be changing that ARIA value over time, you know, that ARIA value. So for a lot of component libraries and things, that can be very difficult to change 'cause you basically have to, like, thread the needle in the source code. So when I was working on, like, WordPress and Shopify sites, I would be going through these very huge stacks of code that I didn't write and just inserting little things of ARIA and it's really not a sustainable way of doing things. So in a lot of cases if a element lacks, you know, the necessary ARIA, like, you're using component library, you know, maybe consider changing the UI and using a different element. So maybe instead of a tab panel, maybe use a different element which has proper ARIA, or use something that is not interactive. So yeah, that's something to keep in mind there. How is it possible for a blind person to perform accessibility testing or the other tasks you mentioned today? You know, TPGi has, you know, blind screen reader test, you know, blind testers and they're able to test a very large number of these success criteria. You know, when you're going through a page, people that use a screen reader are really trained, you know, on what, you know, they really are accustomed to what certain things should be announced as and they are able to recognize when things are not being announced that way. And screen readers provide so much functionality on a webpage, you know. Again, like, all these different ways to navigate the site and to slice and dice the site into a way that, you know, is understandable for them. So, you know, one thing, yes, visually-impaired testers here at TPGi, we help them with color contrast testing. So that's a handoff that we do during our own internal accessibility, you know, testing. What other questions here? I think that was it.

- [Stefani] You have a couple.

- I would disagree with the comment that color contrast is not an impact. If the page does not have sufficient color contrast, sufficient contrast, the viewer may not see text at all. Well, I agree, but again, you know, that would be if the page has, like, zero color contrast or very, very low color contrast. But if something is, like we were talking about, like monitor calibration, like, oh, it's a 2.7 to one on one monitor and it's a 3.2 to another, which would be passing, you know, it's not a substantial difference, you know. And a lot of times, you know, color is not usually the only way of conveying information, I find in sites, you know. Like, a lot of context can be determined from other elements on the page. Screen readers don't have that benefit of viewing an entire page at once, right? They're on a single element at a time. Single elements is being announced. So one of the AAAs is enhanced color contrast. Yes, well, you know, and the AAA is seven to one for color contrast. So it's actually a very restrictive standard. So I've never heard of an organization trying to conform to AAA for color contrast. Now, I disagree with limited times and funds. When a building is built, there needs to be enough time and funds to make it accessible. I strongly agree with that comment. I agree with you. And that's, again, what the ARC Empowerment Program is about. It's about creating these, embedding these accessibility testing processes into an organization so that we are not having that question of limited times and funds about something that is already in production, that is something that is close to being released. So I agree with that answer, but by the same token, I am trying to make accessibility testing something that is achievable and can fit, you know, my perspective is always some progress is better than none.

- [Stefani] Aaron, there were a couple more in the Q&A.

- Oh 3.2 to one is not passing, it is passing, yes, for large text. It's not passing for small text, for normal text. And yeah. Okay, great. That's, I think, all of the questions we received. So yeah, those are really good comments. I really appreciate the questions. And so again, as we've noted, the recording will be shared with everyone and we'll have some other good resources in that email to people here. So thanks for coming. You know, accessibility does not happen by accident. It's not the default. Requires, you know, knowledge and effort and commitment like people here today, so thank you. All right, enjoy the rest of your day, everyone.

- [Stefani] Thanks, everyone.

- [Aaron] Bye.