- [Instructor] Hello,
and welcome to the introductory product walkthrough video
of Deque Systems, axe Auditor.
As you may already know, axe Auditor is a testing tool
that Deque is using to record
the results of your assessment.
Axe Auditor offers both automated and manual testing
from the same user interface.
And since axe Auditor is built on the Deque-way and utilizes axe-core,
you can be confident in testing results
and propose solutions
found in the final accessibility report.
In order to get you prepared for your assessment results,
we will look at a sample axe Auditor report.
In this example, we use Deque's Recipe Dashboard website
for our report.
It should be noted that the Recipe Dashboard website
is a test website prepared by Deque Systems
and has built to model common web accessibility issues.
Deque performed an accessibility assessment on this website
using WCAG 2.1, A and AA standards.
These standards are published by the W3C
and are commonly considered the level of compliance
digital products should meet
to be the most accessible to the widest range of users
and to have the lowest legal risk.
The test information details can be seen
in the test run overview page in the axe Auditor.
To see an overview of the results,
we can click on the view dashboard button.
To navigate to issues directly,
we can click on the view issues button.
First, let's click on the view dashboard button.
Once we are on the dashboard page
also called the test run overview page,
we can see a high level overview on our website's
accessibility conformance,
the impact of the failed checkpoints on our users,
plus the top issues that were detected.
In our example report,
we can see that the Recipe Dashboard website
has a total of 22 issues,
and that we passed 63 of the 79 Deque checkpoints.
Of the 22 issues discovered we found no checkpoints
that were considered total blockers
for our users with disabilities,
our biggest point of failure,
but the three issues found related to color contrast.
To find out more about each reported issue,
we can click on the link in this graph.
Clicking the link will take you to a full list of issues
related to that impact level or checkpoint.
Further down the page, we can see
our website broken into components and pages,
these are the test units we saw on the dashboard.
Depending on how your website
or other digital product is structured
and what features you are testing,
the number and type of test units may vary.
If we look a little deeper into a test unit,
we can see a myriad of information,
including the name of the unit, the URL of the unit,
the unit type, the selector that was focused on
during the unit testing if applicable,
and any instructions for testing the unit.
For example, login and password credentials.
In addition to the basic unit testing information,
we can see that both automated and manual testing
are set as complete for the 79 checkpoints
in the unit test.
If we look at one test unit,
we see that out of 79 accessibility checkpoints,
this component has seven failed checkpoints,
62 pass checkpoints and 10 checkpoints
that are not applicable to this unit.
To learn more about each unit,
we can click the review button to see the full checklist
and there states.
After clicking this button,
it sends us to a page showing
all of the accessibility checkpoints tested
in the axe Auditor report for this unit test.
These checkpoints are broken down into categories
based on the WCAG conformance level
indicated on the reports set up.
As we scroll down the page,
we can see the checkpoints are grouped into categories
to help us identify areas that could impact one another.
In our test report under 1.4 distinguishable,
we see that audio control marked up as not applicable.
We're also testing for text color contrast.
For color contrast regular text, we fail,
but for color contrast large texts, we pass.
The information conveyed on this page
is more general in nature
and might not help us solve the actual failures
found on the axe Auditor report.
If we want to learn more details about the failed issues,
we can go back to the test run overview page
and click on the issues log link for each test unit.
When we click this link, it opens a new page,
showing all the issues related to this particular unit,
in our case, the tile component.
On the issue overview page,
we see a table which includes the issue ID,
the summary of the issue,
the WCAG checkpoint the issue falls under
the issue type, the impact the issue could have on a user,
blocker, critical, serious, moderate, or minor,
the method in which the issue is found,
either manual or automated,
the test unit issue falls under
and the group name of the test unit if applicable.
On this page, we have a lot of options
when it comes to filtering,
searching, sorting, and exporting.
For example, we could review only manual tests
or we could filter by a specific checkpoint.
In this example, we are filtering by color contrast,
or maybe we want to search by the ID of the issue.
There are a lot of different ways to find the information
you need on this page.
To export the data,
you can select the issues you want to share,
and then click the actions button to export the data
into CSV or JSON format.
The export will contain the same issue level data
that exists in the UI.
This export tools, especially handy for sharing data
with those who may not have access to the UI,
or if you prefer to work with the information in Excel
or some other spreadsheet tool.
By exporting the issues to the JSON format,
you can prepare the data to an upload,
to a ticketing system, such as JIRA.
To learn more about a specific issue discovered
you can click the double arrow icon
or the issue ID number.
Both display the same information,
just one method chose that as a new page,
and the other keeps it in line.
Since the information is the same,
it comes down to user preference
on how you want to drill down to this data.
Once you're viewing this content,
you can see the following information,
who conducted the report,
which specific checkpoint the issue falls under,
the issue type, the user impact,
the method in which the issue was found,
when the test was started and completed,
information about the test unit,
source code, description of the issue,
this might include automated responses
and additional notes from the tester,
recommendations on how to fix the issue,
which also might include automated responses
and additional notes from the tester,
a view more information about this issue link option.
By clicking this link,
it takes you to an external axe-core rules page
where the issue is explained and more detail.
And finally, a common section
where you gonna add any additional notes
that may be needed.
If we go back to the initial page,
we started on, the test runs homepage,
we can now click the view issues button.
This action takes us to the issue overview page,
which includes every unit test
and every issue reported by the axe Auditor tool,
all in one page.
This page is similar to the singular unit test page
we saw earlier,
but this time we are seeing all of the reported issues
in one place.
That ends our quick video tour
of Deque Systems axe Auditor tool.
As you can see, you'll be provided with a high level view
of your assessment results,
as well as the details your team will need
to locate the source of the issues,
and tips on how to remediate the issues.
We hope you found this video helpful
in preparing for the delivery of your assessment results.