Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DSpace continually works to improve the usability and accessibility of the user interface for all users, including those who use assistive technologies such as screen readers.  In addition to working to provide accessible design and features, DSpace's user interface does not interfere with assistive technologies that users may use to navigate web-based applications in general.

Conformance status

The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA.

The DSpace User Interface strives for conformance with WCAG 2.1 level AA. However, as of this writing, we are partially conformant because of limitations noted below. Some AAA criteria may also be supported.  We consider any non-conformant code to be a bug and ask you to report it as detailed below.

How we test for accessibility

Development on DSpace is active and ongoing and we use several methods to ensure accessibility for both existing and new development.  

  • We use design principles and coding standards informed by accessibility concerns as documented in User Interface Design Principles & Accessibility
  • We run automated scanning accessibility testing tools (Axe by Deque) across our the user interface in our end-to-end tests (run via Cypress). These automated tests run for every GitHub pull request submitted to our user interface codebase.
  • We also contracted with Deque for an accessibility audit of the DSpace 7 application in Spring 2021. Their feedback was used to inform our design and coding standards.
  • We ask institutions who use DSpace to share any of their accessibility testing results with our developers. Issues found are turned into bug tickets for developers to address in upcoming DSpace releases.

Known limitations

Despite our best efforts to ensure accessibility of DSpace, there may be some limitations.  Below is a description of known limitations:

  1. DSpace tracks all known accessibility issues in our issue tracker with the "accessibility" label: https://github.com/DSpace/dspace-angular/issues?q=is%3Aissue+is%3Aopen+label%3Aaccessibility
  2. DSpace development is primarily volunteer-based, and therefore some accessibility tickets may be waiting on a volunteer to claim them.  While we do our best to ensure severe issues are addressed quickly, minor or "paper cut" style issues may not receive attention until a volunteer gets to them.  However, we accept contributions from anyone (in the form of GitHub Pull Requests). 
    1. If an issue is important to you and you have developers on staff (or can hire a service provider), we ask you to consider contributing a fix back to DSpace.  We ask that you let us know about any fixes you plan to contribute by commenting on the issue ticket.  That helps ensure no other institution will duplicate your work.
  3. As the DSpace User Interface allows users to upload content, we cannot ensure the quality of user contributions.  DSpace does strive to build features that allow for accessible content, but some limitations exist
    1. The MediaViewer (used to view video/audio content) supports subtitles/captioning. However, the captioning files must be uploaded separately at this time.
    2. Thumbnail images (generated from uploaded files) and logos do not yet support custom alternative text. See https://github.com/DSpace/dspace-angular/issues/1306

Reporting accessibility issues

DSpace considers all accessibility issues to be bugs.  Our goal is to achieve and maintain WCAG 2.1 level AA compliance.  We encourage you to report any issues you find, as we regularly improve accessibility in our major and bug-fix releases.

...