Search analytics and insights training - accessibility auditor
Accessibility auditor examines web content for accessibility compliance against version 2.1 of the Web Content Accessibility Guidelines.
Using Funnelback’s underlying crawling and filtering technology, millions of URLs are examined for conformance on a regular basis, with conformance able to be examined over time. Once configured, a successful run against a collection will provide a series of reports via a web-based user interface for logged-in users.
The WCAG standard defines twelve guidelines that detail how to make website content accessible. The guidelines are organised into four key principles known as the POUR principles which stand for:
-
Perceivable
-
Operable
-
Understandable
-
Robust
Each principle consists of a number of rules and guidelines for ensuring web content is accessible. These rules and guidelines are then broken down further into levels of compliance, which are general ratings that websites strive to attain.
-
Level A (single A).
-
Level AA (double A).
-
Level AAA (triple A).
Success criteria and techniques
-
Success criteria are the standards of accessibility that need to be met in order to achieve WCAG compliance.
-
Techniques are the recommended ways in which these criteria can be met. There can be different sets of techniques that can be used to meet a single success criterion, meaning that WCAG compliance is possible while still recording technique failures as a technique failure does not necessarily indicate failure to comply with WCAG.
Accessibility auditor analyses the web content from HTML and PDF documents as the pages are gathered and checks the content for WCAG compliance, producing a report on the WCAG compliance and also providing advice on how to correct the detected errors.
Limitations
-
Funnelback accessibility auditor implements a subset of checks from the WCAG 2.1 standard. While the tool assists with gaining WCAG compliance, it can’t certify that a site is compliant because many of the WCAG checks cannot be implemented by a computer and require human intervention.
-
The accessibility audit reports produced by Funnelback only cover HTML and filterable PDF documents.
The Funnelback accessibility auditor tool is a great tool for checking your site for accessibility compliance, but should not be the only method used to check content. The auditor tool only checks the accessibility of machine-readable HTML and PDF content. A large number of checks required for full WCAG compliance require manual checking.
Accessibility auditor summary
The main services page within the insights dashboard displays a summary of the current accessibility auditor conformance for the service.
Accessibility auditor overview report
The accessibility auditor overview provides a snapshot of the accessibility compliance of pages belonging to the current results page. This provides an at a glance summary of the current performance, and also a way to immediately see the affected pages at each accessibility level.
The screen is made up of a number of widgets:
-
Overview: A one-line summary of the accessibility audit for the service.
-
Compliance to WCAG levels A, AA and AAA: Summary of how the service meets the different WCAG compliance levels, with the ability to see the documents that fail to meet the level. Clicking on one of the tiles opens up a document report restricted to that WCAG level.
-
Summary: Provides an overall picture of the current state of the accessibility audit for the service. The widget includes three tabs:
-
Documents: pie chart that segments the service into affected documents (that do not pass all the machine checks), unaffected documents (that pass all the machine checks) and unchecked documents (that were not audited).
A report on unchecked documents can be accessed by clicking on the small exclamation mark that will appear next to the documents count below the chart. -
Principles: provides a star rating of how well the service rates against the four principles of the WCAG specification.
-
Levels: provides a summary of the documents that pass the automated WCAG A, AA or AAA checks.
-
-
Reports over time: shows how the service has performed over time. The widget includes two tabs:
-
Issues: shows the number of failures and potential issues that need review detected over time.
-
Documents: shows the number of affected/unaffected and unchecked documents over time.
-
-
Top failures: shows the most frequently occurring failures.
-
Most affected documents: shows the documents affected by the most failures.
-
Domains: provides a summary of failures, potential issues that need review and unaffected documents by domain.
Tutorial: Viewing accessibility auditor reports
-
Log in to the insights dashboard, select the Foodista results page then select accessibility auditor from the left hand menu, or click on the accessibility auditor tile.
-
The accessibility auditor overview will load:
-
Examine the overview summary message and the summary tiles for compliance against WCAG levels A, AA and AAA.
-
Examine the summary widget. The documents tab is selected by default showing a summary of the current document compliance.
The chart is broken down into pages affected by at least one accessibility issue, unaffected pages and documents that could not be checked by Funnelback. Clicking the help icon next to the title opens a help window.
-
Select the principles tab to see how the service rates against the four WCAG principles. The star rating is computed based on the number of documents and number of checks that Funnelback performs for each principle.
-
Select the levels tab for a summary of compliance by WCAG level. The bar chart plots the number of documents that attain each WCAG level.
A document is considered to have obtained a given level if all the checks performed by Funnelback for this level are successful. Note: this does not guarantee compliance at the given level as the WCAG standard includes accessibility checks that must be assessed manually.
-
Examine the reports over time widget. By default, this widget displays the number of issues affecting the service over time. Your widget will be displaying a No data found message as the accessibility auditor has only run a single time. Once accessibility auditor runs again the screen will update to look more like the screenshot below.
-
The documents tab displays the affected, unaffected and crawled documents over time.
-
The top failures widget shows the top success criteria and technique failures that affect the service, ordered by the number of documents affected.
Opening the success criteria tab shows the top success criteria failures. More information such as the number of affected documents and WCAG level is displayed on hover.
-
The techniques tab similarly shows technique failures by the number of affected documents.
-
The most affected documents by success criterion failures widget lists the top five affected documents, by the number of failures detected.
Clicking view all affected documents opens the documents report.
-
The domains widget displays a summary of the failures of grouped by domain (as indicated by the document URL).
Each domain item provides a total number of documents checked and counts for the number of confirmed, likely and possible failures.
The domain list can be filtered by domain by entering a domain into the filter box.
The domain list can be sorted by domain, or by the number of documents.
-
Click on a domain name to open a domain summary. The domain summary mirrors the overview report, but is limited to documents from the selected domain. Observe that the left hand menu also expands to show domain level sub-reports.
Accessibility auditor documents report
The documents report provides a document-centric view of the WCAG compliance for pages belonging to the current results page. The report lists documents that are affected by WCAG issues sorted by the number of issues.
This report can be used to prioritize which documents should be fixed first. For example, reduce the total number of affected documents on a site more quickly by fixing those with fewer errors, or make high value changes by identifying and fixing errors that affect lots of pages.
The report offers a number of refinement options allowing the report to be focussed on more specific tasks. Various facets allow the documents report to be filtered by various attributes such as sub-folders (URL) or WCAG compliance level (levels). Keyword filtering is also possible and will filter the report to only documents that include the specified keyword(s).
Clicking on the document title opens the document report for that single document.
Accessibility auditor document level report
The document audit report provides detailed information on all the detected failures and issues that need review for an individual document.
The report consists of a number of panels:
-
Document audit summary: provides an overview of the number of detected failures and issues that need review as well as the WCAG levels that the document fails to comply with.
-
Failures: lists each failure, grouped by the POUR principles, that were detected for the current page sorted by the number of times the error was detected. The issues are grouped into issues and issues that need review.
-
Source code: shows the source code of the document.
Clicking the audit again button runs a real-time audit of the document. This allows for fixes to be made to the document and the changes checked in real time.
Clicking on one of the success criterion shows the different techniques that have generated failures against the criterion.
The icons on the left indicate the confidence of the machine checks:
| Icon | Name | Description |
|---|---|---|
Confirmed Failures |
The machine check is confident that this is a failure. For example, a form which does not contain a submit button. |
|
Likely Failures |
The machine check found an issue but needs a human to be sure. For example, a link which has a one word textual description such as "more" might not be specific enough, however a human could verify that it makes sense given the surrounding context. |
|
Possible Failures |
The machine check found an element in the document that usually requires extra accessibility related resources, but is unable to verify if these exist. For example, the check found a video but cannot check if it has subtitles. |
Clicking on a specific technique failure provides further information on the failure and suggested steps on how to resolve the issue. The source code also highlights the regions of code where the error was detected.
Clicking on a highlighted error or selecting view summary from the failures popup menu opens a window with information about the issue, how to fix it and also provides an administrator with an option to acknowledge the issue.
Success criteria report
The success criteria report details the affected documents broken down by success criterion. The report can be filtered by WCAG level and POUR principle allowing an administrator to focus on the failing success criteria, and thus prioritise which techniques need to be addressed to attain the desired level of WCAG compliance.
Clicking on an individual success criterion (either in the listing, or in the bar chart) opens a screen providing more detail on the specific criterion.
Techniques report
The techniques report lists failures against specific WCAG techniques.
The issues can be filtered by various attributes.
The table of issues provides the issue name and number of times the issue was detected as well as information on the WCAG success criteria and levels that the issue affects.
Clicking on a technique will load a technique level report showing information about the technique and pages that are affected.
Tutorial: Techniques and success criteria reports
-
Log in to the insights dashboard, select the Foodista results page then select accessibility auditor from the left hand menu, or click on the accessibility auditor tile.
-
Open the techniques report by selecting all techniques from the left menu.
-
The techniques report provides similar controls to the documents report. Hovering over an issue and selecting view affected documents will open up a documents report with the current issue applied as a filter. Clicking on a success criterion will open the official WCAG documentation on the criterion.
-
The success criteria report shares the same layout, but reports on success criteria. Open the report and spend a few moments inspecting the report.
Techniques report
The techniques report lists failures against specific WCAG techniques.
The issues can be filtered by various attributes.
The table of issues provides the issue name and number of times the issue was detected as well as information on the WCAG success criteria and levels that the issue affects.
Clicking on a technique will load a technique level report showing information about the technique and pages that are affected.
Acknowledgments
An acknowledgment can be used to manually mark an issue to be ignored. Many of the WCAG checks are not black and white and will only be an error in certain circumstances that cannot be determined by a computer.
This means that a number of checks will be marked as needs review - because manual review is required to determine if the issue is actually a failure.
When creating an acknowledgment options are available to control the scope of the acknowledgment (whether it affects just a specific occurrence or wherever the issue is found) and also to record justification for the acknowledgment (in case an audit trail is required).
Creating acknowledgments
Failures can be acknowledged from the document level report by selecting one of the acknowledged items from the failure’s popup menu, or by clicking the create acknowledgment button on the details popup window.
This opens the acknowledgment screen which allows the failure to be acknowledged. Options are provided to define the following:
-
Acknowledgment type: choose to ignore the failure (because perhaps you have mitigated the failure in another way) or pass the failure (because the failure is only in certain circumstances and you have verified that it’s actually a pass).
-
Reason: Provide some information justifying why the acknowledgment is appropriate (for audit purposes).
-
Scope: Define a scope for the acknowledgment - does it apply to just this specific error? anywhere the error is detected? etc.
Managing acknowledgments
The acknowledgments screen (accessed from the left hand menu) lists all the acknowledgments that have been created for the service and allows an administrator to manage the acknowledgments.
Tutorial: Documents report and acknowledgements
-
Log in to the insights dashboard, select the Foodista results page then select accessibility auditor from the left hand menu, or click on the accessibility auditor tile.
-
Open the documents report by selecting all documents from the left menu.
-
Filter the report to only include items affected by WCAG level A by selecting the A category from the level filter. The listing updates with items affected by WCAG level A issues and an indication that the report is filtered to WCAG level A.
-
Apply an additional filter to show only the items that contain a confirmed failure. Select the failure category from the issue type filter. Observe that the applied filters update.
-
Select one of the affected documents to load the document-level report.
-
The success criterion failures panel displays all the detected issues, grouped by the four principles and sorted by the number of times the issue was detected in the page. Click on a success criterion to show the individual techniques that have had failures detected.
-
Find out more about an individual technique failure and how to fix it, or tell Funnelback to ignore the failure by clicking on the highlighted region within the source code. Before clicking on the issue make a note of which issue you are selecting.
Acknowledging an issue instructs Funnelback to ignore the issue when future checks are performed.
When acknowledging an issue a number of things need to be defined:
-
How this failure should be acknowledged within a page - by a CSS selector, fragment of HTML or for every occurrence of the failure. This allows an acknowledgement to be created that selects multiple occurrences of the failure within the page.
-
The scope of acknowledgement needs to be defined - allowing the error to be ignored everywhere, only on pages within the current domain or just on the current page.
-
A reason justifying why the acknowledgement is acceptable. This provides some basic auditing that can be used to explain why an acknowledgement was created and who created it.
-
-
Create an acknowledgement for the selected failure. Enter a reason into the dialog then press the save button to return to the document view.
-
Locate the issue that was just acknowledged and observe that the it is now marked as acknowledged.
-
Observe that the issue that was acknowledged is now highlighted blue.
-
Click on the acknowledged criterion or the edit control for the criterion to edit or delete the acknowledgement. Clicking the view acknowledgement menu item or clicking on the blue highlighted code opens the acknowledgement editor.
Click on the acknowledgements link in the left hand menu to list all the active acknowledgements. Edit an acknowledgement by clicking on the label in the issue type column. Delete the acknowledgement by clicking on the delete icon.
