WWDC2019 Session 514

Transcript

[ Music ]
>> 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.