Auditing Web Content with Web Inspector

Hello. I'm Jonathan Davis, web technologies evangelist for the Safari and WebKit teams. Welcome to Auditing Web Content with Web Inspector. In the process of building web content, developers have a lot of details to check. Maybe it's following a CSS class name convention or ensuring good accessibility on the page. There can be so many details that they're easy to forget and tedious to find the issues. A built-in checklist would be ideal. Some teams set up automated testing in a continuous integration system using technologies like Safari's WebDriver, available for macOS and now iOS. WebDriver is a great tool for catching code changes that break expected functionality for users. But for web developers who want to check that their in-progress work meets code expectations, Web Inspector now includes a new audit system available with Safari 13 on macOS that provides a quick, easy and more convenient way to check web content. In this video, I'll show you how to use audits in Web Inspector, how to work with tests and understand their results, and finally I'll cover how to create custom audits for your projects. To get started, you'll need to enable the Develop menu to access Web Inspector.

Just load up Safari Preferences, click on Advanced and click to enable the Show Develop Menu in Menu Bar option.

Now just load up a web page and open Web Inspector from the Develop menu. Or use the keyboard shortcut Command-Option-I.

Let's take a look at WebKit.org as an example. Click over to the audit tab.

And in the left sidebar is a list of audits. Click the arrow to the left of an audit to expand it. An audit is a collection of test groups and tests. Test groups don't have any functionality except to act as organizational containers for a collection of individual tests. It's easy to run audits. Click the Start button to run all of the available audits. Or you can right click on an audit for a contextual menu with more actions. To run a single audit, right click on the audit and select Start. Or you can hover over the right area of the side bar and a play button will appear. Or click to select it and press the space bar. Audits are fast and update in real time as tests are completed.

Another way to control which audits are run is to click the Edit button at the bottom of the navigation sidebar.

Here you can toggle the checkboxes on the row next to individual tests, test groups or entire audits to selectively enable or disable them. Click the done button at the bottom when you're finished editing. A list of any collected results will appear below the audits in a results folder with each of the results collected into Run folders.

Expand the Run folder to access the results of the audit for that run. The result runs are kept available across reloads of the page so you can modify the webpage and rerun the audit for updated results. That way you can compare the pass rate for example. Results will be cleared when Web Inspector is closed.

Clicking on the results of the demo audit run displays a report that shows example result levels and result data.

The first three result levels should be familiar if you've ever used XCode. The passed level shows a test that's passed, meaning the code met the expectations of the test. Warning is a soft pass. It says even though the code passed the test, there are things that could be changed. Failed tells you the code did not pass the test.

The other two result levels are special to audits in Web Inspector. An error result occurs when the JavaScript being run for the test throws an error. Unsupported is a special case that can be used to indicate when the data being tested isn't supported by the current page, such as when there's some missing API. Test results can also include data from the test in the form of DOM nodes or error messages.

Web Inspector includes some built-in audits by default which can be disabled but not deleted. One of the default audits provides tests that check a webpage for mark-up that meets some common guidelines for good accessibility.

Let's dig into the results of running the accessibility audit on WebKit.org.

The overall score shows that WebKit does fairly well. But there's room for improvement.

In the failure cases shown in the results, the DOM node where the failure was detected is shown as an interactive DOM tree. Expanding the DOM tree for the node allows you to access child nodes. And hovering over them will highlight the specific elements on the page, just like using the elements tab.

This makes it trivially easy to understand what code in your web content needs improvement.

To fix this, I can simply click this arrow to go right to the node in the elements tab. The problem is elements with the role of menu need their child elements to have a role of menu item.

So I simply need to add a new role attribute with a value of menu item to each of the child elements of the menu. I'm going to quickly add the missing attribute to each of these elements.

Just a couple more.

Okay. Now I'll switch back to the audit tab so I can rerun the audit and see the new results with these changes in the DOM.

Perfect. The page now passes all of the tests. I simply need to incorporate those changes into the actual code for the site.

You can see how easy it is to spot problems and fix them all conveniently within Web Inspector. Audits and audit results can be exported and re-imported. Click the Export button to save the results into a JSON file. They can be re-imported into Web Inspector with complete access to the results, including interactive DOM nodes, when elements on the page match the nodes in the report.

You can also export the built-in audits to see an example of how to write your own audits. As most teams will have their own unique code objectives, writing your own custom audits is one of the most powerful aspects of using the audit framework in Web Inspector.

They use a JSON format to make them portable. Each test is simply a stringified JavaScript function giving you a simple framework with special access to more data than you can normally access in JavaScript. Being simple JSON, it's easy to share your tests with your team or other developers. There's an example ESLint audit available on the WebKit blog post about creating Web Inspector audits. The blog post goes into detail about how to write a custom audit as well as other powerful capabilities of using the audit framework. Simply download the ESLint JSON file and you can easily drag and drop the file onto Web Inspector to import it.

Audits in Web Inspector are quick and convenient, so I hope you'll give them a try using the built-in accessibility audit on your own web pages.

Use the portable audit format to create your own audits and ensure in-progress code meets your project standards. And we love hearing from you and hope you'll file bug reports for any issues you find or feature requests you might have. For more information and additional resources about what I've covered, use the links in the resources section associated with this video.