Tech Check: Digital Accessibility Tools

Transcript for Digital Accessibility Tools Every Company Should be Using

Good afternoon, everyone. Welcome to AccessibilityPlus 2021, my name is Kevin McDaniel and I am the editor in chief for accessibility.com. Today's session is titled, Tech Check: Digital Accessibility Tools Every Company Should Be Using. We're going to talk about some of the assessment tools, some of the applications that your organization can download and incorporate into its testing processes, as well as some of the assistive technologies you should be familiar with and assessment methodologies you should be familiar with when evaluating your organization's website for accessibility.

So first on our agenda is-- we'll be discussing contrast-- excuse me, color contrast checkers-- what are they, what do they do, are they important. And in the next we'll talk a little bit about website accessibility scanning tools-- what type of tools should you be incorporating into your accessibility scans and how much weight you should put on the results of the evaluations.

We'll talk about assistive technologies and I have some fun snippets about assistive technologies that you may enjoy. Regards to the types of assistive technologies, we'll discuss what screen readers are and which ones are used most commonly in the community. We'll talk about what screen magnification software is and how it's used. And then what the speech-- how do speech input work? And how is it used in the digital environment.

This is actually a pretty important piece. I worked with a lot of professionals in the industry and I found that this is something that's skipped fairly often, but the use of it has a serious impact on the way many people with mobility disabilities interact with the web. And then finally, we'll talk about the manual testing methodologies like WCAG-EM or the Web Content Accessibility Guidelines. It's evaluation methodologies.

So how can we use these tools and expertise to evaluate a web content? All of this in its entirety, I believe is a great start if your organization is working to assess the accessibility of your website technology and begin the process of implementing an accessibility initiative. So first, let's talk about color contrast. Why is it important? For one, it affects persons who have low vision and those who are color blind, but it's also just not very usable if you don't have a compliant color contrast. Let's take a look at this first chart here.

So here, we have different levels of color contrast from great, to good, pass, bad, to worse. And I was actually a little bit surprised at the passing 4.5 to one there. Because as you can see, it's certainly not very visible and not very usable. And so this is something that we see very often in promotional materials even in web content in the photo of websites and unfortunately even some of the older content. People love colors but it's really important to have a sharp contrast.

And so of course, the 4.5 to one does pass but we could do better, if possible. And there's a lot of different color contrast combinations, I think that can be used, we just have to be creative. So what type of color contrast combinations are more frequently used in flyers? And I put this chart together here just to kind of show you the different combinations.

The red on blue here it's really frequently used in the ADA. In fact, on the 25th anniversary of the ADA, the Department of Justice put out their celebration collateral, which used red and blue, which were great. They looked really, really good, but if you're not careful, if you use them too closely together it becomes a color contrast issue.

So in this first line, the A, B, C, D, E, the color contrast on that, if anyone was checking was 7.3 to one, so that's OK. The second was just below 4.5 to one, that's the yellow on blue. And by the way, what we're looking at right now is two charts. One with five sections that go from great to worse, that have the color contrast values listed. And then the second chart is the letters A through Z and the numbers one through four, and each line has a different level of color contrast.

And so as I said, the first one comes back at 7.3 to one, the second F through K, which is yellow on blue comes back just below 4.5 to one. The third is 6.2 to one, which is almost a light teal against blue. And then again as I said about the ADA, the red on blue, a very common combination is only 1.8 to one, so we need to be careful.

Finally, the fifth is barely legible, which is the purple on blue, W through Z. And that color contrast came in at 1.1 to one. And then finally, I was a bit surprised when I put this chart together. The beige on blue color contrast, one through four, the beige on blue came back in 5.5 to one. And again, the color contrast we're looking to get here is 4.5 to one-- that's the passing. But again, as you can see, 4.5 to one is still-- we can do better. So how do you do this? It's not with the naked eye. So you need a tool to assess your code contrast.

It can be difficult to gauge what acceptable is. So you don't have to do it with your naked eye. You do need to have a code contrast tool or a process to check the color contrast. On the computer of anyone, that is publishing digital content, whether it's a developer or a designer or a content creator, even customer service representatives who send out content to customers, if they're responsible for creating content that has a different background color, the foreground color that has not been approved by the company, I would advise that you allow them to have this color contrast checker on their site and hope they may try and pull that up.

For me-- and I have a couple of other tools to show you, but for me this is my favorite tool. It's the TPGi Color Contrast Analyser. Anyone can use it. Just download the application from the TPGi website. Once you've downloaded it and you've opened the application, you'll see these dippers here, which allow you to-- you just activate the dipper and use your mouse to select the colors that you would like to evaluate.

So I have this tool pinned on my taskbar and I use it daily. The first thing that I do when I'm reviewing the site is I review the color contrast and my thinking there is that, if you have content that fails color contrast on your home page or you're sending out content that has some very exotic color combinations or color palettes that are not very friendly to persons with low vision or those who are colorblind, my first thoughts are we probably have a lot of work to do on your website because this is a pretty basic requirement.

And it's actually one of the first things most I think, accessibility professionals learn. That an alternative text. So I would advise that you find-- you identify Color Contrast Analyser. This one's really great. It's been called a couple of different things, but if you google Color Contrast Analyser, you should have no problem finding it.

Of course, having spent most of my time in government, I understand that we can be limited in what we can install in our computers sometimes by our IT departments. So until you can get approval to get this installed, to get a color contrast type of tool installed, another great option is to use WebAIM's Color Contrast Checker.

The only issue you'll have here as you can see in the-- on the slide here, I apologize. On this slide, we have three-- we have a list here. One that says, WebAIM: Contrast Checker. The second says, Microsoft Paint and the Chrome Color Contrast Analyser Plug-in and then we have an image that is a screenshot of the Contrast Checker provided by WebAIM.

And so the only issue you'll run into when you use this is you do have to have a specific value. It doesn't have a dipper tool. So you'll either have to have the HEX value or the RGB value and you'll have to be able to convert it based on whatever the original data you have was. So and doing that can be easy. Finding out what the color is, the HEX value or the RGB value. Sometimes you can find it in CSS.

If you don't know how to allocate the CSS of a web page, you can use Microsoft Paints dipper tool to select the color, take a screenshot of the website-- excuse me, take a screenshot of the website and identify the different colors and then convert them to the proper values and they'll give you an assessment of whether or not that color combination passes. And then of course, you can utilize-- there's other, if you google, Color Contrast Analyser, you'll get a dozen or so tools that are available.

But another one that I like to use is the Chrome Color Contrast Analyser Plug-in which allows you to analyze contrast right from your Chrome browser-- from the browser. So the next thing I want to talk to you about is scanning tools. And I want to stress for everyone who works in the accessibility field that's participating in this conference today, to our partners, these are just my go-to tools. It doesn't mean they're better than others. There are some really powerful tools out there and I encourage everyone to research these tools and find out what fits them best.

For me, these are just tools I'm comfortable with and that I use almost supplementally but I think that there are must haves for folks who work in accessibility. The first image on this slide is a screenshot of the WAVE WebAIM toolset which-- excuse me. Is a very powerful evaluation toolset that they can identify WCAG accessibility errors. It works really well when it's used with manual evaluations.

WAVE also supports the Chrome Plug-in and it makes evaluating website very easy. It's just a click of a button once it's installed. If you have Google Chrome, just google the WAVE Google Chrome Plug-in and install it on your browser. When you're ready to evaluate it, you'll notice that there's an icon installed in the Plug-ins menu and it's as simple as just going to a website within your browser and then selecting that icon and allowing it to evaluate.

The second image in the slide is a screenshot of the Functional Accessibility Evaluator, which is a product by the University of Illinois. I was fortunate enough to hear a talk about one of the developers of this tool, a professor at the University and has been one of my go-tos ever since.

It works very similar to the WAVE accessibility evaluation tool. It does not have a plug-in, however one of the great features of this tool is that once you've created an account with the University of Illinois, you're given access to scanning on multiple levels, which means that instead of just evaluating a single page, the tool will assess the type and site structure and can evaluate, I believe up to three levels down.

So the reports are compiled in a report and provide new cost. So where-- the WAVE webbing tool set will evaluate the page in question-- the page that you've landed on, the Functional Accessibility Evaluator will evaluate the site, go through your menu and look at multiple levels of pages and evaluate up to three levels down. So again, the only caution I give everyone relying on these tools is that this should not be your only evaluation method. These are great stats, but technology is always improving, it isn't perfect.

You're going to encounter issues when you run-- when you use scanning tools like false positives, being able to identify code that's not really relevant to the scan. So if you use scanning tools alone, you're going to likely miss out on quite a bit that you would find in a manual evaluation. And we'll talk about what manual evaluations are and how they can be used for folks looking to incorporate them into their testing process.

So we talked about color contrast analyzers, we talked about automated testing tools like scanning tools. And we'll get to manual evaluation methods. But some of the other tools I want to talk to you about are more user-based tools, assistive technologies. And it's really important to understand what these assistive technologies are, how they're used, because they're representative of how users with disabilities access your content.

So if you don't have assistive technology incorporated into your testing process, you're going to be very likely to miss out on quite a bit. So this slide is titled What is Assistive Technology? And it has a definition here. It says, that the United States Access Board defines assistive technology as any item, piece of equipment, or product system-- whether acquired commercially, modified, or customized, that is used to increase, maintain, or improve functional capabilities of individuals with disabilities.

Again, the objective of assistive technology is to make all of your information-- make information, programs, and services and even physical spaces, facilities more accessible to the user of the equipment. So for example, a person who is blind may use a screen reader to access information online to apply for a job or inquire about a service. Someone who wants to access a facility who has limited mobility may use an Automatic Door Opener to access the front door. It can be anything that helps an individual with a disability access services.

Categorically speaking, assistive technology can be anything from mobility devices to screen magnification software. It's again, anything that improves access. So when you're assessing for digital technology, it's just important to understand the variety of assistive technology types and how they interact with your content. Before I move on to the next slide, that I do want to just say because I always try to advocate for this, there really is no substitute for community-based testing.

Users of assistive technology are going to be the best judge of what's accessible and usable to them. So while you definitely want to incorporate assistive technology into your process, I would advise that you incorporate users of assistive technology into the accessibility initiative in the beginning so that way, you've baked in user testing, you can create user-- accessibility user stories because you're actually interacting with the community and with the users who will access that content that way.

But nonetheless, I think that assistive technology has to be part of your process. So I want to just kind of go through that. So what are we talking about when we talk about assistive technology? This isn't really a new concept. Assistive technologies and adaptive technologies have been around for centuries. And in this slide, the slide is titled, Adaptive and Assistive Technologies in History. It has a picture on the left of one of the first known-- well not the first, it was-- this is an image of a wheelchair in the 16th century in Spain.

And it just has a conceptual drawing of what a wheelchair would look like. A functional wheelchair that has some controls and this was developed for, I believe it was King-- oh, I'm so sorry. I forgot. But this is 16th century Spain. Is not one of the first wheelchairs, one of the first wheelchairs, actually one of the first verified used wheelchairs dates back to the 5th and 6th century BCE when Confucius was actually documented to use the wheelchair.

And when you're trying to understand assistive technology, it's just really important to understand that this concept is not new. Another significant point in history, the assistive technology was a bit later in the 19th century, when hearing aids were developed which ultimately replaced the ear trumpet within 50 to 60 years, which dated back to the 17th century. And I apologize, let me read this out for everyone.

On the second point here it says, hearing aids date back to the 17th century and were adopted in mainstream Europe by the close of the 18th century when hearing aids move from a conceptual stage to implementation. The third point on the slide talks about Braille. And it says, in 1824 Louis Braille learned about a writing system called night writing, which was developed that used-- developed to use heavy and raised black ink. And a really cool point about this was the night writing system was actually developed by Napoleon Bonaparte to allow soldiers to communicate at night.

And everyone knows he's-- what an effective and innovative general he was. But Louis Braille in 1924 took that process, the raised ink-- the thick raised black ink and modified it to create a writing system for persons who are blind and ultimately it was called Braille. And lastly, and I know I'm skipping a lot of assistive technology for folks who are big fans of assistive technology-- things like the radio which actually I'll get to in a moment.

Talking books and screen readers but one of my favorite stories was another huge development in assistive technology which was in 1971 when Julia Child's cooking show became one of the first television programs to broadcast captioning technology that it just been federally funded and approved in a conference the year before. So that's just kind of fun facts about that.

And then finally, on assistive technology, and I'll continue to move on here. I'd just like to say-- I'd just want to show how some of these original concepts-- this is just human innovation. That's what assistive technology is. In 1928, the government began distributing radios to promote access to information for people who were blind. And in 1935, in response to that, folks have radios, the talking books began to broadcast first in Canada and later in the US. And of course, that's led to audible books and all types of different ways we interact with technology.

A lot of folks also don't know that text messaging is often attributed to the modified use of the deaf tone system. Characters from the alphabet in the '90s, using the deaf tone system were used-- conceptually used by a forklift driver who wanted to send orders to forklifts for accuracy. And in that process, they ultimately discovered these text messaging.

And then finally on this slide, one of the examples here, it says, Voice Assistants-- Siri, Alexa, Hey Google. And that's what these-- I have two images here. One is of an image of a man in the middle-- evil ages interacting with an iron brazen head which is-- which is a tool that they used to develop to try to emulate the human voice. And what they would do is they built these out of iron and they fed them with steam and they would try to build them so that they would again, emulate the human voice. And usually it was yes or no answers.

But as you can see in the image here, there's a man standing in front of this-- in front of this brazen head asking a question presumably and he's frightened by the response. And so you can see that for years, we've always tried to improve our surroundings and to create technologies that are not just novel but are functional.

And then I put this second image here, which says, "What can I help you with?" And it's a screenshot of Siri-- I like to think how this guy would've reacted if someone said, "hey, Siri" in the middle of his session with the brazen head. I'm sure it would have blown his mind. So today's assistive technology. Something that every person testing for accessibility should have in their belt is the use of screen readers.

The first one I have on this slide, I apologize. Let me describe it. This title-- this slide is called Screenreaders. The first item on it says, JAWS from Freedom Scientific. Next is Windows Narrator, then NVDA, TalkBack, Google, and VoiceOver, Apple and then there's a screenshot of NV Access with the text that says that, "We believe that every Blind, Vision Impaired person deserves the right to freely and easily access a computer." And so screen readers are technologies that allow people who are blind to access the internet without the barrier of trying to interpret the content using one sensory function alone, which is psych.

JAWS, Freedom Scientific was one of the first. They were kind of the leaders screening technology. Was developed in the '80s by a gentleman who worked at IBM originally. Freedom Scientific currently holds over 50% of the market. So over 50% of people who use computers and not mobile who have vision disabilities are still using JAWS, Freedom Scientific. And finally, we have Windows Narrator and NVDA.

And then for the majority of folks who are on the internet now and I just read an article the other day that said that 53% of the global traffic online is through mobile now. And so, you have to imagine that TalkBack through Google and VoiceOver in Apple-- both the screen reading, touch screen speech, the Text-to-Speech technologies are being used more often than some of the older computer screen readers.

But the important point here is that when you're testing your website or any technology for accessibility, you need to incorporate these assistive technologies because these are how folks who use assistive technology interact with your content. If you create a mobile application or a mobile website and you haven't tested it for functionality with Apple's VoiceOver, then ultimately you're on the risk of accidentally discriminating against people who use this functionality.

If you're providing a service-- if you're a government or a higher education, you provide a mobile application that allows you to pay for your child's lunch through an application but that application wasn't tested for VoiceOver, parents who have low vision or parents that are blind who try to access the application and it doesn't have VoiceOver support, are not going to be able to participate in the program or service the way it was intended.

So it's just really important to have all of these tools in your toolbelt. And of course, some folks who test for accessibility are going to prefer one over the other but I highly advise that you incorporate all of them. At least, one of the screen readers-- the computer-based screen readers and then the Google and Apple VoiceOver functionality. You have to test it. Those are different environments and they require different types of support.

Next, we'll talk about screen magnification software. ZoomText is-- oh, excuse me. Let me describe the slide. The slide is called Screen Magnification Software and the list here says, ZoomText, MAGic, Windows Magnifier, Pinch to Zoom, and then Control+/Control- and I have two screenshots here. One of accessibility.com's-- one of our blog pages at 110% zoom and in the second screenshot is of the same page of 400% zoom.

And the most important point here is that, your content needs to be-- your text, your images, any digital content you display needs to be-- you don't want to lose the context-- you don't have a change of context or lose the-- well, you don't want to lose context as you zoom in and out of the content. So ZoomText is one of these tools and I'll go through these tools that will help you determine whether or not you're responsive enough if your content meets that guideline, if it meets the 200% to 400% threshold.

ZoomText first here is a combination of magnification in screen reading technology, it's really tailored to low-vision users. Similar-- MAGic has some similar functionality. It gives users the ability to zoom in without losing their mouse pointer from 1X zoom to 4X the screen size. So it includes a built-in color enhancement tool as well and it has speech options. It's really used more commonly by users with low vision or limited vision.

Windows Magnifier is a great tool. I use it. It's free, it costs nothing. You can activate it right now as we're talking to test it out. It's a built-in feature of Windows. This feature gives you the ability to use your mouse as a magnifying glass. So anywhere you point on the screen, it's automatically enhanced and you have controls that allow you to see how much you'd like to magnify which you can set by default.

You can turn that tool on by pressing the Windows key and the Plus button and test it and then when you're finished, you can-- to turn it off, you get Windows plus the Minus key. And then finally, there's Control+/Control- which is a very quick way to just test for the accessibility. Do you meet the 200% threshold, the 400% threshold? I'd recommend finding a place on your website where there's an image or an image of text or even just text if your site is not built-- if your sites not responsive, it's not going to zoom properly.

So to find out whether or not there's a change of context, whenever you zoom in or out of your website, I would recommend you start with Control+/Control- and then you can use Zoom Magnifier to see how the content interacts with the tool that people who have low vision and use those tools will actually encounter. So next, this is a feature that I included to demonstrate why accessibility should be incorporated into the design in the first place.

Yes, your technology may be coded and built to meet accessibility requirements and it may be compliant but it's not-- it doesn't mean it's always going to be usable and as accessible as it can be. On this screen, it's titled Speech Input and there are five images. The first is Accessibility.com's home page with Windows MouseGrid activated and the grid shows the numbers one through nine, and it's broken up into nine squares, and within each square, there are nine additional squares. And the reason for that is because the grid is used to zoom in on specific content.

The second image is of zooming in further using the grid which I'll explain in a moment. And then the progression goes on until we get to the link we want to click. So Show MouseGrid allows the user to navigate content and place the mouse wherever they'd like by voice. These images show the progression of that in selecting content that way. So if we want to click on one of the top navigation menu links at the top of our page, we've got to get the mouse there with our voice. To get that, we'll have to select box 2 in this image.

Now, to activate speech input, you can go to your settings, your Windows settings and look for Voice Control or Activate Voice Input, I believe. And when you do that, this-- to activate this toolset here, you say, Show MouseGrid. And Show MouseGrid will activate this grid. And then the grid-- first, I just kind of have the progression. So we want to get to that top link. We'll say-- we'll say, show MouseGrid, and then we'll say two. When we say the number 2, it's going to zoom in on that top box at the top middle, number 2 as you can see in the second picture, which then activates another grid, one through nine in that section.

So we want to Zoom In further. And in this case, we'll select box 5. When we select box 5, since it's over the physical accessibility link, it'll zoom in once more and we'll select that-- we'll say zoom 2, now the MouseGrid is centered right over the word physical. Now that we have a box that's directly over the link itself, we need to click-- we need to use, we need to activate the left click of the mouse.

So we'll say, click five to activate mouse left click area-- left click on the area. And when we do that, it's just like your left clicking on your mouse and it'll activate the Menu item here. So as you can see, there's quite a bit of difficulty navigating content this way. So we can't remove all barriers. And while we can always-- we can strive to be 100% compliant, there's always going to be accessibility issues.

There's no real accessibility guideline that's going to help us overcome the difficulty in using our voice to access content in this way but it's just really important that you as a designer, a developer, or as a project manager, or as a person in leadership of your organization understand that accessibility is not an endpoint. It's an ongoing goal. It's something that we need to work to achieve and we're only going to really understand the usability and accessibility of our sites if we incorporate people with disabilities in our testing and our user experience.

So and again, there's just no WCAG guideline that can solve this issue that I'm aware of. So it's just-- but it's important to understand that these are some of the challenges that many of your users have and they rely on these types of assistive technologies to access your content. So our goal is to try to make this content as accessible as possible. Remove unnecessary barriers and try to create very simple content and design in a way that incorporates all these different viewpoints and user experiences.

So and one last thought on this. And what I mean by barriers, unnecessary barriers. Imagine if you have flashing content or pages that constantly refresh. How difficult do you think it would be to navigate the content here if it refreshes every five seconds? Just to describe to you and to create this display took even longer because you have to print screen, you've got to Show MouseGrid. Number 5, number 2, number 5, number 2, click five.

Now, imagine in that time that I was-- and that's if Windows works properly and it understands my voice every single time, which it doesn't. But imagine if by the time I got to click five, refresh or flashing content appears. How difficult is that and how unnecessary is that for someone who already has this challenge in accessing content because of the assistive technology limitations that we still have.

So it's important to build with your user in mind. Design with the idea that simplicity and unnecessary barriers-- unnecessary barriers may be removed and simplicity and usable accessible design is key. And again, I just can't stress enough incorporating users with disabilities into that. It's the only way you're ever going to recognize these types of barriers that go beyond WCAG.

Had I not worked with people who use this functionality, I probably would not even be aware of it, regardless of the standards-- or the guidelines, excuse me. One last thought on that. For folks who use speech input, you want to make sure that your links and any interactive content are properly coded to work with these types of technologies. So Show MouseGrid is great if you don't mind spending 15 seconds trying to move your mouse from one side of the screen to the other.

But if we're accessing an accessible site like this, we have all of our links are properly coded and they can be accessed. One trick that the Speech Input function gives you is allowing you to say something called Show Numbers if the voice is activated. And when you say, Show Numbers and let me say what's on the screen, it's titled Speech Input and there's a screenshot of AccessibilityPlus, October 12 through 14 2021 home page. And there what appears to be which it's not but what appears to be an overlay on top that shows-- that provides a number for all of the clickable content on the site.

And so in this case, if your site is accessible and you've tested it with this feature and users can reliably log on to the site or access the site and use this feature if all the links are clickable, instead of having to use MouseGrid and spend all that time going from one side of the screen to the other, they can do something called Show Numbers and it allows them to say-- and in this case, I'll say that-- I would say Show Number 64 which is over here on the left side of the screen and number 64 in this case is associated with our Home button.

And so if this was coded properly and this site is, saying the number 64 would automatically activate that Home button instead of forcing the user to move their mouse across the screen using a grid. So it's just something to keep in mind when you're building your site. That's why again it's so important to test with different types of assistive technologies.

So you have assessment tools, you have-- you've used the Color Contrast Analyser to test some surface level things, you've used an automated assessment tool like WAVE or FAE. So what do you do to catch these other things after you've worked through all the assistive technologies? You've asked your QA to test with assistive technology, you've got a high level scans done, you've checked your color contrast. How do you test this against WCAG guidelines?

This can be a scary process, especially if you're new to accessibility because you look at these requirements, there are many and you're trying to decide, where do we start? Do we start with non-text content, do we start with captions, do we start with how robust our site is. Luckily, the Web Content Accessibility Guideline Evaluation Method, which was created by the Web Accessibility Initiative of the W3C have developed a tool for us to use to take this step-by-step from beginning to end.

So and let me just kind of-- this title is called-- this slide is titled, WCAG-EM Website Accessibility Conformance Evaluation Methodology. And it says, Use of WCAG-EM and there's a link to the reporting tool. So the definition here though, is WCAG-EM is a methodology that describes the steps that are common to processes for comprehensive evaluation of the extent of conformance of websites to WCAG-EM 2.0.

Typically, WCAG-EM is going to be used by web consultants who want to analyze the accessibility of their site, web accessibility evaluation service providers, website developers, website owners and procurement officers, website compliance and quality assurance managers, and training staff and educators as well as web masters and content authors. So it can be used by many-- by anyone as long as you're comfortable getting started with it.

So I'm going to walk us through it very quickly so you can kind of get an overview of how you would use this tool. Now, there's other ways to evaluate your site using the guidelines-- using WCAG but this is a great place to start if you need to take it in byte sizes. So first, when you visit their site, you'll see that there's kind of an overview that gives you an idea of how the tools you use. There's a lot of jargon, a lot of acronyms. Even for IT professionals, accessibility can definitely be overwhelming.

But the reporting tools was developed to help us navigate through this process. So the best way I can describe the tool, how to use the tools for folks that are new to accessibility, is that it's like going through a checklist or creating a training program is to do it piece by piece. It wasn't-- Rome wasn't built in one day and learning how to test for accessibility, articulate the results, and then summarize them can be difficult to do if you're kind of taking a scattershot approach to it.

My only advice is for you just to take it step by step. You can save, you can go back to it. 10 years ago, I was asked to manage an IT piece of a large lawsuit and I didn't know, of course, that it was-- just a small sample was to come. But the first thing that I learned was that images needed to have alt text. The next thing was keyboard focus and then on it went. Captioning and all that good stuff.

But when you're learning this, it's also best to take it piece by piece. And this tool allows you to do that. You can-- it provides you tips for using the tool, it talks about how this tool is used, and it also has great links to WCAG techniques and failures. So it's a great place to start. So here we are. We're at the overview. And again, I apologize for not subscribing. This slide is titled, WCAG-EM report tool and it's a screenshot of the first page, which is to have an Overview of the WCAG-EM reporting tool.

So you learned about assistive technologies, color contrast analyzers, automated testing methodologies, we're ready to put that to action and so we need to go through some type of manual evaluation. So the second piece of this is where we get started. The first thing you're going need to do in a web evaluation is to find the scope. In the first field, we're going to give our website a name. So here I'd advise that you give the name of the site that's based on its purpose.

So for example, if I'm XYZ Bank and I'm evaluating a customer log on page, a great title may be XYZ Bank Log On Interface. And the reason for this is because you may have different-- many different functionalities within one site and if you think about all of those things, a log on, a membership page, presentation or informative content, interactive content. All of those will have different technologies that are used and have different types of supports and different outcomes.

So if you name the site XYZ.com Bank or XYZBank.com, it may be the name of the site but it can be confusing if your team has to test all the different functionalities of the site. So the second thing you need to do is to define the scope. This is-- is content for your mobile browser, is it a web content for the public facing-- for public facing customers or employee portals. We need to define that. Is this where users log in? Is this for-- is this a landing page for marketing. We just need to explain what that is for future use.

The third field asks you to select WCAG version to use, you only have two options right now. WCAG 2.0 and 2.1. My take on this is that 2.0 is the most commonly referred to by the Department of Justice. They've started referring to 2.1, I've seen in a few documents and honestly, I don't think it hurts if your organization works to strive to 2.1. But I do think-- I do think there's legal precedent in various settlement agreements and enforcement activities that would make justification 2.0 easier to sell to leadership if that's the position you're still on.

But if you can, 2.1 of course, is the latest and greatest-- and not to mention, 3.0 of course, is right around the corner. And so the closer you can get to the most recent version of WCAG, the easier it will be to transition, I think to the next version. 2.1 has a lot of it in it. In the next field, you'll need to select the performance level you'd like to meet, which is A, AA, AAA.

I think the consensus at this point and some may disagree, is the point you need to be at is AA. The one A was the old baseline, which I was always led to believe was roughly the equivalent of section 508 requirements. The problem with that, though and a lot of folks may say, well, if it's A and I'm section 508 compliant, the only issue with that, though, is that the federal government is now requiring federal agencies to meet AA. That's the old requirement.

And again, most Department of Justice settlement agreements and Department of Labor, Department of Education agreements, they don't really refer to A anymore. It's kind of the minimum at this point. AA is what-- is the acceptable level and I've been in various cases as SME, AA is the goal. AA are better. AAA, I think that you should work to meet the level of accessibility that you can. Again, I think the accessibility goes beyond WCAG. It's a user-experience question and there are some things WCAG can't solve. They're user-based.

So I think that you should go as far as you can, but for me, AAA is more of an aspirational goal just because of the cost associated with some of the requirements. They're very difficult to sell to leadership. So if you're trying to establish an accessibility program, on a project management standpoint, trying to get all your stakeholders in line, trying to ensure that everyone's on board, trying to convince your IT department that it can be done, that your digital transformation will be successful, to me AA is the best place to start.

But I mean, and on top of that, there are requirements in AAA that can't be solved with technology. It makes the cost very hard to defend. And for example, providing interpreters to all live content or I can-- so a lot or pre-recorded but there's just some challenges associated with AAA that it's one of those things if you can meet parts of AAA and go above and beyond, that's great but I think that AAA is very difficult to sell to leadership.

And whether you've started an accessibility project or you plan to, you'll learn that too. So finally though, you need to define your accessibility support baseline. When we develop new applications and websites, we decide which browsers, which viewports, which outputs, and which types of technology we're going to support. Accessibility is no different.

In general, my argument would be that if you're planning on creating content that is supported on three browsers, you should provide accessibility support for all three of those browsers. And the same goes for assistive technologies. If you're developing responsive content on a mobile application that uses responsive technology to output a website it's like an applet, you need to support the accessibility features of the device that will be accessed with. And again, that goes back to understanding all the accessibility features of the devices that you plan on your content being viewed on.

And so finally, you need to define any additional evaluation requirements. Is this evaluation going to be used on a select sample, on the entire site. Is it just the accessibility of the content through one type of browser, all that needs to be defined. Who's this test for, that kind of thing. And I promise not all of these are as long as the first page but I want to kind of go through it.

So section 2 here and on the screen it's called-- on this slide it's titled, Explore the Target Website and there's a screenshot of the second-- or excuse me, it's titled The Second Step but it's technically the third tab on the weekend report tool titled, Step 2: Explore the Target Website. Here we need to state which technologies are relied upon. I'm sorry, I got ahead of myself there. To provide the website. So for example, was the site built in HTML or CSS, or is it a database with XML, XHTML, PHP.

The options in the image here-- let me-- here we go. The options in the image here-- HTML, CSS, ARIA, JavaScript, SVG, and PDF. Below that however, you can add web technologies in the URL for each language specification. And of course, you could learn this language specifications on the 3C's website. So in the first box below optional exploration notes, is that you can add notes about the essential functionality of the website.

So for example, user login or registering on account. Those are important details that need to be added when your reports are reviewed by leadership. Are you testing a specific part on the site, a specific page, or a specific functionality, you need to document that. And then finally, in the variety of web pages text field, you need to notate the types of web pages you're testing.

So you can say home page, wireframe with one main section in a side, two navigation menus in the footer. We're not really thinking about the number of web pages here, but we want to talk about the variety of types of pages we're testing and what's contained within those web pages. What type of structure, what kind of technologies.

The next slide is titled, Select a Representative Sample and there's a screenshot of the WCAG-EM report tool. And on step 3, select the representative sample. Under this tab, the first two fields are carried over from the previous step for your reference. So this first piece here, the structured sample in the variety of web page types, whatever text you typed in on the last page will be carried over to those two fields and they're used really just for your reference.

In the structured sample section, you're going to see-- you're going to select web pages that reflect the data you've input so far. So the purpose of this section is to help you select the samples that reflect the technologies that the site utilizes. So the more accurate you hear-- the more accurate you are here, the smaller your sample size can be, which is, of course, going to reduce testing time and cost of resources. So you want to select samples that can incorporate all the technologies you intend to test.

Don 't list technologies that are included in the site and then forget to test them. It's really important to get a good healthy sample size of the different types of technologies. And then finally, on the the randomly-- excuse me. On the randomly selected sample size, you need to select web pages that are not included in your representative sample. But the number you select needs to be determined on a number of representative pages.

So for example, let's say in your structured sample web pages, you have 100 different pages you need to test because every single one of those pages has some variety or some different type of technology or a variety of types of technology used together. Under your randomly selected sample page, you want to select 10% of the number of structured sample web pages. 10% of that number but those pages need to be selected from the website and not included in your structured sample website.

So let's say you select 100 pages for the structured sample web page, you need to go to the website and find 10 more pages that were not included in the structured sample web page and then test the randomly selected sample to find out if you have a good, healthy view of all the technologies viewed. So your sample size should do a pretty good job of incorporating all the technologies that are in your structured sample web page sample size.

That's kind of the idea behind that. Select your structured sample web pages and then select random pages to see if you have successfully captured all the technologies that may be included in the structured sample web page. And in step 4, I mean, this is the-- on this slide, we have two screenshots, one step 4 which is titled, Audit the Selected Sample Size and then there are several text boxes that allow you to input content.

The text boxes are titled-- are not titled but they're sectioned off within different various parts of the guidelines. The first one being Perceivable and then 1.1, Text Alternatives. And then a text box that allows you to enter your observations. Again, this is why we're taking it step by step. The reporting tool-- the great thing about this is it has really conveniently located links to understand what each requirement is as well as how you can meet the requirement.

So once you reviewed each requirement using any of the tools that you think are relevant to that requirement, for example, you may want to use the color contrast tool, or the assistive technology toolset to ensure that-- let's say the assistive technology to ensure that your non-text content actually has a-- actually has alternative text to it or is properly labeled. This is where you would enter in those observations. Test it with NVDA, labels read properly, or alternative text reads properly.

But you didn't put your feedback here. And then under the checkbox here, for each section, the options or either passed, failed, cannot tell, not present, or not checked. And in this screenshot I have not checked because it's an example. And then the second screenshot are just examples. Resize text is one of them, 1.4.4 in the observation here. Is text can be resized to 400% without loss of content or functionality. That's a real result, that's an observation from your test that can be used later to determine what type of modifications need to be made.

So again, there's a section for each and you'll see right above the text box, there's two links here-- one that says, understanding and then how to meet. That's where as I said, as you go through this piece by piece, when you get to a requirement, if you don't understand it, these links are very convenient, they'll help you understand it. Go back, test it, enter your observations.

And then finally, we're going to include a title in our report. The report commissioner-- whoever commissioned the report, your leadership or IT. Add the evaluator's name, which would be you. Which is important for tracking purposes on the evaluation day. And then we'll include an executive summary and record any evaluation observations that we think are relevant and should be included in the summary.

This is where you want to incorporate all your overall findings, which of your observations are about the accessibility of the site, any prominent barriers that you think may be a challenge to overcome. The frequency of those barriers and any other types of accessibility issues and any other patterns that you see in the technology that may create barriers.

Once you're finished, and this first screenshot reflects that, it's a screenshot of step 5 titled, Report the Evaluation Findings and then all of these text boxes that I just described. And in the second screenshot, is the report that's been generated. Once you're finished, it'll generate a report that contains all of your findings with a timestamp and action-item list. And I just advise that you keep the report for all your future records.

And again, I would just say that some of this may seem daunt-- excuse me. Daunting but that's why it's so important to incorporate users of assistive technology in your evaluation process and assistive technologies in all of these evaluation tools so you can get a full and comprehensive view of the accessibility of your content. But I know this is a lot but I thought it was really important to go over the evaluation tools that are available.

These are all starter tools, there are certainly more powerful tools out there, but if you're building an accessibility initiative, I believe these are the must haves and this is where I started. So and these-- and a lot of these tools I still use every day. So with that, I will wrap up here and I look forward to any of your questions. And again, thank you all for joining us today for AccessibilityPlus 2021. Thank you so much.