Skip to content

Requirements

Romain Deltour edited this page Jun 2, 2017 · 1 revision

Technical Requirements for an EPUB accessibility checker

These requirements have been written to plan the project, in August 2016

Overview

The DAISY Consortium is initiating a project to develop an accessibility checking tool for EPUB content, under the Accessibility Baseline initiative. This page describes the requirements for the tool.

The objective is to develop an open source tool to enable the publishers and service providers in implementing the accessibility baseline specifications, and to enable distributors and consumers (like procurement centers etc.) to check the accessibility claims of the publications.

What this tool will do

The tool will perform a variety of automated checks to assist in the evaluation of conformance to the EPUB Accessibility specification. It is intended to be used only as an aid, and is expected to be integrated in a broader evaluation process which should also involve manual inspection.

The initial version of the tool will be able to check EPUB 3 content, and check against a variety of rules defined in WCAG, ARIA, and HTML, following the versions referenced in the relevant EPUB specifications.

The tool will be usable as-is, or can be integrated as a third-party tool in broader publishing workflows or authoring processes. It will be an open source project.

What this tool will not do

It is impossible to perform a 100% complete evaluation of accessibility requirements in a fully-automated manner. Many criteria require human judgement and manual inspection. Therefore, the tool does not claim to be a yes/no validator or a certification tool, but rather intends to be used as an aid in the evaluation process, providing adequate guidance to the human operator, for drastically reducing the man hours invested in accessibility checking.

In particular, the tool will not issue any accessibilty score, percentage of conformance, etc.

The tool itself will not perform any change to the evaluated content, it is not intended to be used as an authoring/remediator tool or a tool to repair inaccessible content.

All the checks will be run in a fully-automated manner. The first version of the tool will not be interactive, but will still allow the development of semi-automated checks where a human is asked to manually inspect the content to complete the evaluation.

The tool will not be able to analyse encrypted content, or any other DRM-protected EPUB that cannot easily be unpackaged.

Requirements

User interface / API

The EPUB accessibility checker must be able to be used as:

  • a Command Line Interface tool (CLI), runnable locally in the user's environment, available on the three major OSes (Windows, Linux, macOS).
  • an Application Programming Interface (API), for integration in broader systems or workflows (as a REST API and/or in the tool's programming language)

Depending on further resources and contribution parternships, we may also develop:

  • a Web application
  • A Graphical User Interface (if possible, cross-platform)

Input

The EPUB accessibility checker can check:

  • a packaged EPUB publication
  • an expanded EPUB directory
  • single EPUB Content Documents (like individual HTML content documents)

The tool will intially target the EPUB 3.x set of specifications.

Output

The EPUB accessibility checker must return a detailed machine-readable report of the list of issues (one issue for each verified criterion failure).

Each issue:

  • must be either associated to a WCAG level or be labeled as EPUB-specific.
  • should include a description and reference to the failed WCAG criterion or EPUB-specific rule.
  • should contain a pointer to the corresponding location in the input, as precisely as possible
  • if possible, should contain a pointer to the technique(s) recommended to fix it.

The checker must also return a summary report indicating:

  • the eventual presence and count of warnings/errors
  • the identified accessibility properties, as can be declared in accessibility metadata

Issues can be of several natures:

  • strict failures
  • warnings
  • identification of something that requires further human-driven inspection

Accessibility Metadata recommendations

  • Provide recommendations for missing or incorrect accessibility metadata to the extent possible.

The output must be available in the following formats:

  • a documented machine-readable format (likely in JSON).
  • A user friendly format for the human operator.

Checks

The EPUB accessibility checker will include various checks:

  • seamlessly integrates all the EpubCheck checks, which will allow users to use only one tool for both accessibility checking and EPUB validation
  • automated WCAG tests (likely based on the work of the Auto WCAG CG)
  • extra EPUB-specific accessibility tests (following the requirements of the EPUB Accessibility specification)
  • check the presence, validity and coherence of accessibility metadata
  • check the use of MathML (possibly commented out)
  • evaluate the structure of SMIL Media Overlays and associated metadata
  • check the rules related to page markers

The evaluation engine will be designed to enable the development of interactive steps. When both automated and semi-automated checks are available, the tool can be configured so that fully-automated tests can be run (for instance to automatically filter out content with poor accessibility, before the content goes to human assistive testing stage).

Configurability

The tool must be configurable to allow:

  • changing the severity level of each check (e.g. moving an A-level check to AA)
  • selecting the list of checks to be run (resp. ignored)
  • setting the level of details (for instance "report only the first 3 occurences of failures to a given criterion", "report all the checks, even successful ones").
  • Automated tests module to reject publications with poor accessibility, before moving to stage of human-assisted testing

Extensibility

The architecture must make it easy to implement new checks, for instance via API hooks or a module system

Run time environment

The accessibility checker must evaluate the DOM and the accessibility tree created when rendering Content Documents, as manipulated by a browser or RS environment.

Is possible, the accessibility checker should be adaptable to several browser engines or reading systems.

Documentation

  • user documentation
  • detailed list of checks
  • developer documentation