The Funnelback accessibility auditor examines web content for accessibility compliance against the Web Content Accessibility Guidelines (WCAG 2.0).
Using Funnelback's underlying crawling and filtering technology, millions of URLs are able to be 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:
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.
Funnelback accesibility 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.
- Funnelback accessibility auditor implements a subset of checks from the WCAG 2.0 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 reports
Accessibility auditor reports are available for frontends within the Funnelback administration interface as long as accessibility auditor has been enabled on the underlying collection(s). The reporting interface consists of several sub-reports:
- Overview - Provides high level statistics for the frontend as a whole, including over-time reporting for the frontend.
- Documents - Provides reports for each individual document within the frontend, which can be scoped via a range of facets.
- Techniques - Provides reports based on compliance against WCAG techniques.
- Success criteria - Provides reports based on compliance against WCAG success criteria.
- Document audit - Provides a detailed audit for a document, highlighting problems within a source view (for HTML documents). The document audit page also allows specific issues Funnelback reports to be 'acknowledged', indicating that a human has reviewed them and that they should be excluded from future reports.
- Acknowledgements - Provides a listing and management functions for acknowledged issues.
Accessibility auditor administration
Accessibility auditor may be enabled for web collections from the 'Edit collection settings' screen, under the 'accessibility auditor' tab. Enabling this setting causes accessibility analysis to be performed on all HTML and PDF documents during document filtering, whenever the collection is updated. This setting adjusts the accessibility-auditor.check collection.cfg setting.
Most user management for accessibility auditor can be performed by managing user permissions on frontends, which will allow administrator users to access accessibility reports for either entire collections, or specific sub-sets (since the accessibility-auditor reporting interface will respect any scoping query processor options specified on the frontend). Generally, users must have the
sec.accessibility-auditor role to allow access to the accessibility auditor reports and must have permission on the underlying collection to work with acknowledgements.