Case Study 6.4: Duke University—An Institutional Repository Audit
Sean Aery, Duke University, described burgeoning efforts in 2019 to assess the accessibility of his university’s institutional repository, DukeSpace. Aery noted that a university-wide Web Accessibility Committee provided a helpful guide for carrying out an audit of Duke’s DSpace instance—minus the materials archived on the platform.
- Goals: To align the accessibility of the institutional repository with other web accessibility efforts at Duke University. Identify and resolve platform-specific barriers to accessibility in the institutional repository.
- Project Scope: Initial focus was on the accessibility of the DSpace platform itself and not the documents and materials archived in the repository.
- Evaluation Criteria: The goal of the audit was to align accessibility with WCAG 2.0, Level AA. Accessibility tasks were drawn from the Duke University guide, “How to Do an Assessment”—a resource provided by the Web Accessibility Committee. The library followed this guide to evaluate keyboard-only navigation, hyperlinks, tab order, heading use, skip navigation links, frames, images, color contrast, flexible resizing, and more.
- Tools: Of particular use for the project was the Deque Systems Axe Web Accessibility Testing Chrome Extension. Aery noted that this tool and a simple keyboard-only navigation test can quickly illuminate many issues on a given platform.
Aery provided a list of initial findings from the audit to illustrate the types of things his team moved to address. These results included:
- Form elements didn’t have associated labels (Main search box needs label)
- Color Contrast problems, < 4.5:1 contrast ratio
- <html> element must have a lang attribute
- Headings progression: no h1 present on item page
- h5 for metadata headers — headings should increase by one
- Landmarks/Banner: Page must not have more than one contentinfo landmark
- Page must have one main landmark (need role=“main” on main content)
- Page must have level-one heading
- All page content must be contained by landmarks (banner, navigation, main, contentinfo — need throughout UI)
- Empty search button: Place text content within the <button> element or give the <input> element a value attribute
- Justified Text: a <p>, <div>, or <td> element has more than 500 characters and is styled with text-align:justify.
- Add Skip Nav Link; should be first in tab order
- Can’t tab to the facets via keyboard
In the future, the team at Duke hopes to implement axe-core to help ensure the accessibility of new software code and avoid the kinds of problems encountered during audits. Ideally, this solution would mean that all new code must pass an accessibility check before being deployed online.
In “Getting Serious about Open Access Advocacy: Ten Practical Repository UI and Metadata Revisions to Help Your Library Champion the Cause,” Aery and co-presenter Maggie Dickson connected accessibility audits back to the library’s mission for equity and inclusion. In particular, they discussed ways that libraries can add value where commercial publishers may fall short. They suggested that by pursuing accessibility, libraries can distinguish themselves in a publishing landscape that often prioritizes profitability. For instance, in his 2019 blog post on accessibility in DukeSpace, Aery noted how an article in the New England Journal of Medicine produced 197 errors in an accessibility check while the same article in the recently audited and updated institutional repository had zero errors. What is more, at the time it was necessary to tab more than 100 times in order to download the article from the commercial publisher while keyboard-only navigation was much more streamlined in the IR.
The full video of Aery and Dickson’s talk can be viewed in the Code4Lib SE 2019 conference recording.
