Tools of the Trade: Accessibility Without the Cost

JEREMY RIVERA: Thank you for coming. This is Tools of the Trade: Accessibility Without the Cost. Super humbled to be here and I appreciate all who can make it in person and then those who are tuning in on the live stream and those that are catching the recording. Before we get into the talk, I wanted to give you all the brief introduction to myself.

This slide contains two images. One of them is a picture of my two dogs. A black lab and a brown beagle. Both are wearing sweaters and looking into the camera.

And the second image is a profile of myself, shaven, smiling with my arms crossed. If you are catching the recording, I do have facial hair today. But I'm a Developer Advocate at Deque. That means I'm a software developer that tries to spend a lot of time with the community, such as events like this, and also give them resources to help them code accessibly or give them the tools to them do their jobs easier.

I try to convey their feedback, whether candid or not, for those in my company. I studied software engineering and communications while I attended the University of South Florida. While I did not study ASL, I knew ASL, I've been with the Deaf community for quite a bit. I'm happy to sign with people.

And I'm a dog dad of two doggies. Milo. He is the beagle. And Luna is the lab.

I'm happy to share I was just recently awarded a CPAAC certification after testing. So a nice first step into the community. So on this slide there is an image of a large red tool box centered within the frame. Now that we've gotten the introduction out of the way, I wanted to begin with a question.

As developers and accessibility professionals, what is in our accessibility tool box? This is a personal question and we all have a very different answer. For other trades and professions, you can probably guess the tools they use. If you can think of a carpenter, they probably use a lathe, a saw, a mallet, a square, a number of chisels.

A painter may need to sketch out their image on the canvas with a pencil before they come back with brushes and paint. Each trade has its tools and accessibility development is no different.

For developers, designers, and engineers, we use tools every day such as our key boards, screen readers, and Integrated Developer Environments or IDEs such as VS code. We are trades people, skilled professionals in a very specialized craft. Our trades rely on different tools for different skills sets, variations depending on the focus of our teams. Our focus today obviously it's those tools regarding how to make accessible development easier.

The tools available for free to build an inclusive experience for all. Like any industry, specials come with high prices, but the tools don't always have to. The tools I will be exploring today can help get you started building accessibly even if your team's subject isn't there right now. There are many teams that haven't gotten the buy-in yet from their stakeholders, but that doesn't mean you can't get started or stop you from trying.

So today's tool box, today's agenda, we will discuss tooling available for three stages of development. Namely when we are writing the code, when we are testing it locally, and when we are reviewing it PR.

And again on this slide, there is a figure that re-iterates simplified software development life cycle. That discussed in the last slide. Namely first beginning with writing clean accessible code. Second, testing locally on chrome-based browsers.

And third we will briefly discuss PRs reviewing and what happens post commit. I wanted to reemphasize these steps to get accessibility issues can be and often do get introduced during each stage of the development. So each stage creates a unique and good opportunity to continuously check and test for accessibility issues.

I'm going to start within IDE. Typically all the code re-write as developers is written within an IDE. Simply put, this is the tool we probably use each and every day if we are engineers or developers. And since using an IDE is crucial, it is super important to incorporate accessibility best practices as early as we can even while we are writing the code.

So here we have a figure that goes into why we are starting with development early in the life cycle. The graph's legion shows the cost in the Y axis and the phase of development on the X axis. There is four phases. Design with the cost of 1X, development with the cost of 5X, QA testing with the cost of 15X.

And production with the cost of 30X. Incorporating best practices from the start and as it shows, it should start with the design phase, but once it's handed off to developers, it's our responsibility to maintain it. If we don't, fixing it later introduces more accessibility defects and quite costly when we consider post production. Each step of the process continues to increase dramatically and according to a Whitepaper released by IBM, the cost of discovering defects after release are significant, up to 30 times more than if you catch them in the design and the architectural phase.

Because this talk is about free tooling, we need to start with the mindset of trying to save money.

So we have to shift left in RSDLC, and bring best practices early. Once it's pushed to practices, you subject yourself to lawsuits, bad PR, when they find you have shipped an inaccessible code or product, so if you fix them early, you don't have to deal with that process. Accessibility doesn't have to be expensive when it's done correctly and done early enough, but it often is because it's typically later in the game that people start.

So since some teams don't have a huge ally budget at the moment, we have to be scrappy with the available tools on the market. Let's start with the Linter. Any images or descriptions I present are going to be from VS Code. I will focus on the tools here.

So on the screen you have ESLint and also the Ax logo.

Both of these can be used in other IDEs. So the ESLint plug in I will discuss can be used in almost any terminal. And the Ax development can be incorporated in IntelliJ if you use something like JetBrains is the name. So it's relatively IDE agnostic.

So starting with the Linter. What is a linter? If you have ever grabbed a ball of dust from your pocket after drying it, you probably encountered lint before. So similarly, in a code repository, there are times in which the code re-write might not be best practiced and might have a little dirt in it.

So in that regard, in programming, a linter is a tool that analyzes your code as you watch it. It checks for errors, inconsistencies, and violations to something. Predefined rule. And can help format, help you syntax, and in this case contact.

If you think of it as a spell checker for your code, it helps you figure out what happens as you write the code.

So what accessibility linters are available? The first one we will be discussing is the ESLint plug in JSX-A11y. You can see the page from the registry that I put here. It says there is a static AST checker for accessibility rules on JSX elements.

I know that is a lot. But it also states if you move further down the stage, that this plugin does a static evaluation of the JSX to spot accessibility issues in React-based apps. It uses in combination with axe core react. To test the accessibility.

Consider these tools as just one step of a larger accessibility testing process and always test your apps with assistive technology. Again I want to point that out that we are going to revisit this. But it's designed for react-based environments. Next JS, vanilla JX.

And it highlights the rules. Such as missing alt tags, the order of certain elements, keyboard traps that might come into play. As mentioned earlier, it's pretty agnostic. You can use it with VS Code, IntelliJ.

If you are bold you can use it with Vim. Some of the rules it enforces, as mentioned alt text.

This is super important. And our roles enforce the elements with our roles have a valid non-abstract role. And something like anchor has content. So that is a very specific rule.

And all anchors obtain accessibility content.

So this here is within a code repository. Again with a VS Code IDE. And what is being displayed on the screen is a specific image component that has an error because an alt tag is missing. This is a NextJS application.

Fun thing, they have built this plugin within their framework and platform. You don't need to download it in addition to the framework. Not all frameworks are like that.

NextJS does a Rell good job here. So what you can see within that NextJS component, there is a red squiggly line. And that will tell you and yell at you when you do something wrong. As mentioned, there is no alt tag.

And -- one solution that you will need if you aren't using NextJS, it will give you the error within the IDE, but once you start to start testing locally within the browser, you won't receive an error. So you have to use it in conjunction with something like Axe or another tool. NextJS team does a fantastic job because they have built that. If you are testing within the browser, they will have that browser-based support that won't be readily apparent if you use Vanilla React.

Alternatives. So another alternative linter is the axe accessibility linter. Which you can download via the extension. You can get it on IntelliJ and other IDEs.

So what makes this different than the previous one? Well, first it's built with Axe developer tools. Those errors will be apparent on the browser. And then two, it has pre-built support for other libraries.

Other component libraries. UI libraries. Google's material UI, a lot of people use that to save time building certain applications. It has pre-built support for that.

React Native is a popular one. They have pre-built support that. If you use it, you can create reusable components and the Axe accessibility linter already knows how to gauge them. And if you create your own component library, you can map it to specific rules so it can also learn how to read that library as well.

So an example of something that might get picked up from one of these component libraries is the MUI button. Which is almost -- it's within a tag. It will already know that button should automatically have keyboard accessibility built into it. Like a native HTML button would as well.

So here is a still image within the IDE VS Code. This is a type-script application. You see an error coming under an image tag. A normal HTML image tag.

And a long red squiggly underneath it. What you get back is a little bit less robust, but in a good way. It shows you exactly where the problem is. And the other one it showed a little bit more in terms of typing.

Because we were using a type script application, but this one goes straight to the point. It's at the Axe linter, the error under the image alt tag, you need to ensure they have alternative text or a role of non-presentation. So you can see what the problem is, how to fix the problem, what rules it breaks, what laws it breaks, and then more information such as the disabilities that are affected with the specific error at hand.

And the specific standard it breaks. It's pretty cool. What you can also see is on the bottom of the image in the terminal on the problems tab of the terminal, it also inputs the error. So that is very useful again because you have a couple points of contact for that error.

But it's also useful if you level up, if you have it within VS Code and you get an API key and there is a trial for that. So we won't focus too much on that. You can use it with GitHub actions. So if you have a commit or a pull request, they can immediately block a pull request if the code is accessible and write those things.

We are focusing on mainly free tools, we won't go too much into that. It can also with the API integrate with something like SonarQube or Jenkins. Like a pipeline. So after we hopefully written accessible code, we are still kind of writing the code, but your application is kind of developing its shape.

You want to test locally in the browser. Many developers are having their IDE on one monitor or half their screen, and then a browser on the other side of the screen so that they can do it at the same time and they get hot refreshing and reloading. So everything is integrated. So on the screen other than the Google Chrome logo, the other logos featured is Google's Lighthouse, WAVE tool, and the Axe browser logo.

The browser tools help you catch common accessibility issues. Again such as alt text. The structure of heading elements. If you go from H1 to an H4 or H1 within two H2s, again sometimes you see that.

Low color contrast between text and backgrounds. Missing labels on form fields or buttons. Elements that aren't keyboard accessible. A lack of proper Aria documentation, and responsiveness issues in terms of how you are using the browser.

We want to talk about Google Lighthouse first. Lighthouse is a free open-source tool created by Google that analyzes web pages to help improve their overall quality. It can be run on any site whether it's public or requires authentication. So think Internet sites, think private sites.

And audits for key areas other than accessibility such as performance, A11y stuff, SEO even, and progressive Webex features. You can run Lighthouse within Chrome DevTools, I believe they have it in Firefox as well. You can run it as a node module. If you are skilled at handling dependencies.

And to use it, you enter a URL and Lighthouse runs a series of audits.

Including score recommendations. And for any failed audits, it provides recommendations on why that issue matters and how to fix it. So on the next slide we have an image of something you would see after running an audit with Lighthouse. You see four little circular graphs for performance, accessibility, best practices, and SEO.

Performance 97, accessibility, 74, best practices 93, SEO 73. Performance measures how fast your page loads and becomes interactive. Includes metrics like first contently paint. Which is how quickly something shows up.

Time to interactive. How page responds to user inputs. Pain twitches. Loading of main content on the website.

The second is accessibility. And as you see, that's probably one of the lowest ones here. But it presumably checks how the site is for users with disabilities. And again, examples of what it might look for is the missing alt text.

When you need to make sure our web pages have alt text for every image. Color contrast images. Proper use of Aria. Keyboard navigation.

You have to make sure the sites you make are inclusive and used by everybody. Best practices is a little bit different. For modern web development standards. It makes sure your site is using HTTPS.

It's free -- it tries to test to make sure you are avoiding common JavaScript vulnerabilities, efficient in resource use in trying to keep your site secure, reliable, and maintainable. SE, it evaluates how well your site is optimized for search engines. What it tries to look for is the proper use of meta tags, making sure that the links are scrollable and the text is scrollable. Is it responsive on mobile?

Is it friendly to you? Do you have a descriptive page title? And after that it will try to help you out in the right direction to make your site more searchable. When to use Lighthouse.

So Lighthouse is really good for quick audit. Its audit is in multiple areas. So it's quite comprehensive in the four that was mentioned. Probably use it in early development, before you commit.

Again you just want to quick test to see where your site lies. You perhaps might use it as a QA for code reviews and if you want that visual score, again the visual circular graphs, those are pretty cool too.

The next tool we will consider is the web aim WAVE browser extension. And this browser extension can be downloaded on most of the major ones. Such as Chrome, Firefox, and Edge. And it's a free powerful tool to help identify accessibility issues.

So let's see how it differs briefly from Lighthouse. As you see on the left side, there is the console, and on the right side is the page you just tested. Immediately you can see the difference because how it generates the report, it shows you your web page, but it shows you little insignias next to the different artifacts on the page. It will show you the arrows and part of the legend on the left-hand side within the console or the specific areas.

So it's very visual. That is the most striking example. You get that immediate visual feedback. So WAVE overlays icons right on the page.

So you can focus on those areas. They both it's 100% local and secure. So it runs entirely within your machine's browser. It does not send data back to its server.

So again, kind of like Lighthouse. You can use it to test Internet pages. You can use it for password-protected content, or dynamic asynchronous JavaScript. But because it's visual, some people might like it so it might be more user friendly to those that have the ability to look at those emblems, but it is also able to be used with keyboard shortcuts which is really nice.

So you can open the tool with Ctrl+shift+U for Windows users and Cmd+shift+U for Mac.

The third in line is Axe Developer Tools. Some key differentiators. It's free to use. You can also use it on Chrome, Firefox, and Edge.

Just like WAVE. And it's also designed to help developers, designers, testers, whoever is going to make those checks, it's designed for them in mind. It runs automated accessibility checks on any web page. It surfaces many of the most common as mentioned alt, Aria, the different ordering of elements.

And it shows where it occurred on the Dom. Guidance on how to fix it. And very similar to the linter we spoke about previously, it will have the link to Deque University where you can look at what disabilities are affected, how to fix it, what rules it breaks, and so on. This is useful because it helps catch those issues early.

It's designed for zero false positives focusing only on issues it can confirm with high confidence. If somehow there is a false positive caught, it gets submitted as a report, like a bug, and we treat it as a bug, and then we try to fix that. So it doesn't require deep accessibility expertise to start using it, but we always recommend to grow in the expertise, to grow, to continue, to learn.

So we have this on screen, but I do believe we are going to do a demo. Yep. We ready for that? Let me see.

Do I stop sharing?

BEN OGILVIE: No, you can drop your -- sorry. You can just drop your browser window. Should be able to. There you go.

JEREMY RIVERA: Okay. So this is going to be fun. Okay. So we have the same site that was tested through both of the other DevTools.

And to open the DevTools, we hit command option I. Go to Axe DevTools. I made sure I'm not signed in.

You run a full page scan.

And immediately 41 issues pop up. So you have total issues such as Aria, the roles, elements must meet minimum color contrast ratio thresholds, alternative text, links have discernible text. You have within the Dom, the location of the element in question. A recommendation on how to fix it and also more information on that Deque University page.

Another cool thing is it shows you with that element is. So we know it's highlighted, it's highlighted in pink. So the element in concern is one of the photo elements and says language on it. And you can also go into code.

So once you know that there is a color contrast issue, if I change that color and I change it to block and I go back and I re-run the scan, I have 39 issues. So that issue is fixed in real time. So that is it with the demo. A very brief demo.

Again if you want to save test, share it with other people, there are pro features to use, but it's really cool to see because it also shows you the laws. If you are operating in the United States or Europe, you have all the laws to be fixed and what the impact is if you don't fix it.

And I have a slide to explain to use the tools as intended. This is really important, and I'm going to mostly read it so we all get it. They are important and they catch a lot but not everything. You can't catch everything yet with an automated tool.

False positives -- again with Axe we have a dedication to zero, but either with Axe or other tools, they can happen and they do happen. Rather you have to be humble with that. So without the best tools -- and even with the best tools, false positives may or may not happen. And even if errors don't show up, it doesn't necessarily mean that the website is immediately accessible.

Just because you have zero errors. To build truly accessible tools, you should and would pear it with manual audits from accessibility experts. And again if you are an accessibility expert, that doesn't mean you can't use the tool. You should use the tool.

But if you have the ability, use it with those experts. And then you need feedback from users with disabilities. And we have to see this more. Users with disabilities that use screen readers on the daily.

You can use a screen reader yourself. And that is great. You should learn how to use one. But how does your website give that feedback if that is not your bread and butter?

So you need screen reader users, you need keyboard-only users, you should have comprehensive testing if you can, and if you have a friend, maybe someone who isn't your co-worker, have your friend help you out. Someone you know that uses these technologies, because that's who you are catering to. And to reiterate, accessibility is and always has been a people-first practice. It's not just a checklist of things to check off.

You need to make sure it's usable by actual people. And so you should incorporate those people early in the testing practice. Super important to reiterate.

So now that we have reiterated that, to recap we have talked about the tools for writing code, we have talked about the tools to have local tests within a chrome-based environment. And I will briefly verbally consider reviewing pull requests. That is where we start to delve into paid stuff. And I promised to focus on the free stuff.

So a couple of these. The logos here represent one of WAVE's offerings and Axe DevTool developer hub. This is the final tools. And they fit in the last box mainly reviewing pull request post commits.

What happens with these, they can integrate via APIs in a greater CI/CD process. I wanted to save these last. When you are starting to consider pro plans and getting more out of automation, these are probably going to come up through Google searches and everything. DevHub can track accessibility across your entire code repository, you can monitor GitCommence, different regressions.

There is a GitHub integration. And you can block PRs with new issues. You can track trends over time. And it makes results very easy to share across teams.

And that is something you are going to come back to when it talks about pricing. It's typically collaboration, overall automation, greater scale. The WAVE API automates page-level checks within your CI/CD pipeline as well. You can submit URLs, it can return JSON XML data.

They can start with 100 free scans. That's what they promise. And then afterwards it becomes pennies. But you will typically buy it in bulk and the price expands from there.

The Axe developer hub API, you can make an account. You get an API key. The API key is good. You can use that.

It doesn't expire. You can continue to use it on a single site. It doesn't expire. And then test it out.

And then if you wanted to branch it off to different code repositories or different sites, that is when you would have to invest a little bit more.

So now I have a brief illustration. When might you start making consideration?

You need results tracked over time. So you want reporting, you want something to get back to your stakeholders, you want to see where you have been and where you want to go. You might want to use something like that. You want to scale across teams, you want to share those results, you want to share the data.

Axe tools integrate with Jira.

You want to share that? You could copy and paste the free stuff and that's a great start, you might want to consider that. You want to integrate it with Jenkins or SonarQube, that is a consideration. And you want structured insights.

But we promise to focus on the free stuff. So we have another illustration. When do you use the screwdriver? The image on screen is a woman who is evidently using a screwdriver to screw into a circuit board.

And she has another tool to hold it in place. But she is using it on a table. And she is really focused on what she is using the screwdriver for.

So what else might you use a screwdriver for? You might use it for something like a watch, something like a dresser, some small scale things. But a screwdriver is an indispensable tool that you probably have several of them in your house. Use your screwdrivers.

The next image, when to use a drill?

What would you use a drill for rather than a screwdriver? They do more or less the same thing. The drills are probably a little bit more expensive. They probably have a little heavier hit behind them, but they also might speed up your job.

They might help you out a little bit in the future. So these are personal questions to consider what tasks would you use a screwdriver for and what tasks would you use a drill for? Would you build a house with a screwdriver? Could one person build a house with a screwdriver?

Maybe. Will it take years versus months or weeks? Does the team need to use it? These are all things to consider.

And only you or your teams can answer that question.

Next we are going to wrap up a little bit. Again a nice encouraging slide here. Free tools does not mean free of effort. So if you are using the free tools, there is still going to be a little bit of effort required.

Choose the right tools for your role, master a few, don't go trying to master each of the different browser extensions. There is a lot of overlap between them. It might not be conducive to your time. So don't chase them all.

Learn how your tools work, not just what they flag. There are errors that will come back -- given back from these tools, but what do the errors mean? What does alternative text for images mean and why are they important? What is Aria's roles and why do you need to know that?

Understand WCAG. One, why we have guidelines. And so you see why WCAG is not a perfect solution. Understand what you are fixing and why it matters to people with disabilities.

Most immediately and I probably should have ordered this first, get feedback from people with disabilities. Just because you have tools, does not mean you can replace lived experiences. There are people every day that can't go on websites because they are inaccessible. Get their feedback.

Incorporate A11y and accessibility into your tool today. Anyone can go and download DevTool extension and use it tomorrow. But there is no excuse with technology we have today that we can't implement A11y earlier. And I found a little quote by Benjamin Franklin.

"The best investment is in the tools of one's own trade." So you can leave knowing that. A great trades person will know the tools, know how to use them correctly, have a plan, and when they build the products, they are learning the guidelines. So your blueprint might be WCAG, it might be design implement it.

Understand why WCAG is what it is and why it's getting updated. Because it is an imperfect principle but it's a fantastic way to get started. You don't have to memorize it but understand the different design patterns within it as well.

And I leave you with this illustration. On the left-hand side is a small white watch and on the right-hand side it is a two-story building with Leopard print. I think the Leopard print is arbitrary. But it's when to use the screw and when to use the drill.

When to use paid tools, versus when to use free tools. So free tools will get you started, but not always finished. But they are still available and please, please use them. And you know paid tooling, they offer deeper insights, a little bit better collaboration with your team and reporting that you can share with your stakeholders.

And here are some resources. And I believe the slides will be available on the website too. The slides have been made sure they are accessible. Without further ado, we have Q&A now.

[Applause]

BEN OGILVIE: All right. Thank you, Jeremy. Awesome. And we do have about 10 or 12 minutes.

So we'll start. I will go back and forth from questions from the room and the live stream. So we will start right here.

Jeremy, thanks for this talk. I'm curious, how would you tailor the advice for someone who is nontechnical and doesn't know how to code and would rely on an AI agent. They wouldn't know how to trust or follow these guidelines.

JEREMY RIVERA: Someone using an AI agent, always corroborate that with the actual documentation. AI agents like ChatGPT, they can give you almost immediate feedback for accessibility, but please check, double check, triple check that feedback. On the W3C and the WCAG website, because that will give you the actual guidelines instead of what is spewed out on ChatGPT.

BEN OGILVIE: All right.

So I have three questions and I will try to make them brief. The first one is it looked like two or all three of the tools you mentioned that are free have links to Deque. I wonder, do you guys have partnerships? How does that work that they have links too?

So that is one. Two, is you mentioned that it listed other countries. And I've done work with a lot of international countries and I'm curious, is it just the EU and the UK and the U.S. and Canada?

Or is it Asia and other parts of the world? And number three, is of those three, there is clearly some pros and cons. Can you tell us why you might recommend we start with one versus another since I think you very smartly said, don't try to master them all and they have a lot of overlap.

JEREMY RIVERA: Yeah. I was going to say I will answer -- yeah. Let me start with three first. Three like she said, there is a biased.

I invite you to try them all. I invite you to try them all. Not all of them have the laws given back to you. They should all be user friendly.

They should all be accessible to try. To go back to number one which was the --

BEN OGILVIE: Partnerships.

JEREMY RIVERA: Okay. The only ones with links back to Deque University are the Axe tools. The linter, the Axe developer hub. And the second one was the different laws.

Not -- so the Axe extension will have the different laws. And I noticed one of them was the EN15309.

That is a European one. They will get more comprehensive when EN gets enforced. But there are other tools in the catalog. Such as monitor where you can choose the rules of the place you are at.

Whether that is WCAG 2.1, single A, double A. And other countries like you mentioned, you can play around with that too. So I don't know. Again because I am biased, but I don't know what Google has.

Kind of a similar thing. Or if WAVE has that explanation.

BEN OGILVIE: One other thing you might notice is a number of the other tools in the space do use as an optional rule set, they do use the Axe core rules that Deque has open sourced. You will find some of the other tools in the space, both the free and paid tools, may use -- at least one of the rules that they will check is the Deque open-source Axe core stuff. You will find Deque stuff available and adopted fairly broadly as well.

I'm going to take one from the online and then I will come back.

So this one I can answer. What level of WCAG does DevTools measure against. 2.1 and 2 .2 and all levels.

JEREMY RIVERA: All the above.

BEN OGILVIE: Do you have rules for triple-A?

JEREMY RIVERA: I think double-A is standard. I know when you get to the comprehensive tooling, you can do different.

BEN OGILVIE: Another quick one. Sorry, maybe not quick. What are you -- sorry, are you aware of tools that work well with container-based content. Speaking of Adobe captivate that works more of a blob than a web page.

JEREMY RIVERA: It depend on what you are testing for. One tool I did cut out of this talk was a mac-based tool specifically created for color contrast testing. You can use it as a color picker. I know if you are using either Adobe in Designer or a color picker, you can use that tool for that specific job.

I know most of the things you are going to use has a built in accessibility checker that will do part of the job for it. I know Design has one.

Photoshop they all have one. But other tools, I don't know.

BEN OGILVIE: If anybody in our brain trust in the room or live stream knows something specific for Adobe Captivate, feel free to chime in or we can route an answer through the newsletter afterwards.

I don't know either. We will do in room.

Not Adobe Captivate but color contrast tools specifically, there are free tools out there you can use for color contrast checks. It's not necessarily stuck to Adobe. There is a free tool you can download to use on mac and Windows I think.

You covered testing locally, but you didn't touch upon screen readers themselves. Jaws is very expensive. Let's not go there.

And media for Windows and voiceover. Voiceover for Mac.

When should we start incorporating screen reader testing as well? That is something that is taken over by large enterprises as separate teams. That is question one. Question two is recording the -- is regarding linter.

WAVE does it work for dynamic?

JEREMY RIVERA: I will say unfortunately I cannot answer the WAVE question. Just because of my knowledge base. The other one was the --

Where and when you would start incorporating screen reader at the developer site.

JEREMY RIVERA: If you have the ability to, certainly post-commit pre-production before you hand it off to the QA. Because the QA might also reiterate that with someone with disabilities. If you have the knowledge or skill set or the personal project time to learn that, I would recommend doing it yourself.

The only reason I bring that up, is because it depends to get pretty personal. Screen reader use especially. We don't do it, if we do it, it's our personal and we keep fighting. [Laughter]

Thanks for the talk. That was very good. That's like a segue. My question was also about screen readers versus using the automated tools.

Because something like form of validation. Everybody talks about it. So you have to use screen reader to do like the tabbing and things like that. Do we have automatic tools for that?

Does Axe or others can detect the talking or whatever?

JEREMY RIVERA: Yes. This is a paid feature. So I will qualify that. So the Axe Developer Tools Extension has something called an IGT.

If you sign in and look through the IGT, it will tab through the site for you. It will show you what elements do not have a proper tag index. That is one of the pro features. And again you can use it, test it out for two weeks, give me the feedback, find me on LinkedIn, it's on one of the slides, and see if you like it or not.

BEN OGILVIE: IGT is short for Intellect Guided Testing.

Okay I think I have more online.

PS, Adobe Captivate is an E-learning development tool.

It exports slides you create to be interactive with online in an LMS.

It exports learning content as slides is how I'm reading this. But it's not a design tool. It's an LMS.

JEREMY RIVERA: It might be depending on how the slides are converted, the work -- again, I can't answer so this is asterisk. Is the workflow might be once it gets to in Design or another tool --

BEN OGILVIE: I think it's akin to Adobe AEM where it's a content platform for producing learning content that gets published to the LMS. So it's not an interface design.

I assume it's kind of more canvas than HTML. But again I'm also not speaking from a place of knowledge. Okay I had one more. How can developers -- this might be related to a similar question that was asked in the room.

How can developers prioritize which tools can use when starting their accessibility journey?

JEREMY RIVERA: It depends what you are using the most. If you are writing the code, start with Linter. Start with Linter. Again you can use it on IntelliJ.

If you are writing the react code and throwing it out there, everyone uses the one I mentioned. The ESLIN.

I think I switched that. But use that. Use those. If you are coding in Vanilla React -- start with the Linter.

Always start with the Linter and with an extension. I will say if you don't want to download an extension, Google is just now starting to throw accessibility tree into the DevTools. So you can do that too. I have found, it's kind of hard, but if you can read that Dom and for some reason you don't want to download an extension, then that can be helpful.

BEN OGILVIE: Cool. We have about two or three minutes. So we will do one more in the room. One more online.

And then for those in the room, stick around, we can continue the conversation after we end the live stream.

Thank you. So my question is you mentioned Axe Dev would not capture all the issues. Is there a site where you might list some of the things that will require testing? I'm sure it will be a long list, but I know there is -- I know will probably be covering Prowl.

But if there is anything. Let's say a freelancer that is doing testing that can access some sort of a list.

BEN OGILVIE: I will say actually Dillon Barrel's book Agile Accessibility, he has a table in the back of the book. It's not to be a Deque. Just -- I happen to know that he does have a table in the back of the book that covers all the WCAG guidelines. It was through 2.1.

I don't know if he has updated it for 2.2. And there is a website I'm blanking on right now, but I think it's A11yautomation.com. Find me or shoot me a note and I can find that. It covers, these are the ones covered under automation, these are the ones that require testing.

There is nuance to it, but it's a useful place to start. I don't know if you have another idea or resource.

JEREMY RIVERA: So I know right now -- I don't know the math. So I can't give it to you. But automation has been a work-in-progress for a little while. If you were in the industry 15 years ago, you had to manually find the color contrast and do the math and figure that out.

I know with Axe the free version will boast up to 57%.

BEN OGILVIE: Of combinations.

JEREMY RIVERA: Of common issues. But like you said the Ebook is free online. And it's a short book. You just rush to the back if you want it.

It has a little ballerina on the front.

BEN OGILVIE: Okay. Thanks to Jeremy for a great talk. [Applause]