1. Making accessibility a priority in digital collection platforms
Libraries spend significant resources digitizing collections, but are the platforms and repositories that provide access to these resources accessible to all users? We make great effort to ensure our buildings are accessible, we need to put the same intention into our digital infrastructure.
Making accessibility a priority in digital collection platforms
Penn State
University Libraries

2. Product Ownership Product owners help ensure services are accessible.
Product owners are the chief stakeholder, representing the needs of all users. They define the vision, prioritize the work, and are accountable for delivering value.
Product owners help ensure services are accessible.
Initiating accessibility testing
Prioritizing development around accessibility
Implementing universal design concepts
“However, it is wrong to say that accessibility is just about disabilities. Really, the aim of accessibility is to make your websites/apps are usable by as many people in as many contexts as possible, not just those users using high-powered desktop computers. Extreme examples might include: mobile devices, TVs, watches, and very old devices.”
A FOCUS ON ACCESSIBILITY OFTEN LEADS TO A BETTER EXPERIENCE FOR ALL USERS.
Try using your digital collections with JAWS/NVDA or the Funkify browser extension. Think about how the experience makes you feel.

3. Software-as-a-service (saaS)
CONTENTdm

4. from self-hosted to Saas CONTENTdm
We had already decided to build a Samvera-based repository for digital collections, but it wouldn’t be ready for users for another few years and we had many issues with self-hosted CONTENTdm.
CONTENTdm 6.x (self-hosted)
CONTENTdm Responsive (SaaS)
Stability and maintenance issues made out self-hosted instance precarious.
Same instance had been in place for 18+ years without ever being rebuilt.
Known issues with accessibility and mobile.
User interface was outdated and not aligned with user expectations.
Hosted at OCLC datacenter.
Stability and maintenance becomes someone else problem.
Promoted as having significant accessibility improvements with responsive, mobile- friendly user interface.
Requested demo as a medium term option for accessible digital collections.

5. Accessibility Testing of CONTENTdm Responsive (Saas)
Always test vendor claims…
Worked with Penn State Enterprise IT Accessibility Group to conduct automated and human accessibility testing of CONTENTdm demo.
Results were disappointing to say the least. Couldn’t enter a digital collection from the home page. Strongly worded s were sent.
OCLC listened to our concerns and their actions demonstrated that they cared about accessibility too.
Too much focus on automated testing, not on the user experience.
Successive product releases showed major improvements.
We migrated to the new version and reduced testing to annually.
… and don’t be afraid to push back.
EIT Accessibility Group provides consulting, testing and training on accessibility for staff and faculty at Penn State.
Testing was conducted by a blind woman using a screen reader. Could not enter a digital collection from the home page. Almost every page element and link other than search results was read before the results. Lots of basic usability issues.
Two reports and recording of the testing was shared with OCLC.
Relying solely on automated scanners to ensure compliance with WCAG misses the boat. A website may technically be accessible, but still be a terrible user experience. This is why hands on accessibility testing is so important.
The values in things like alt text matter, but automated testing can’t always tell if they are what they are supposed to be.
OCLC has been very upfront about this, I presented at Best Practices Exchange with them a couple weeks ago to talk about this.
Content and metadata are out of scope for this presentation on the platform, but there are considerations here too, sometimes harder to address.

6. Cultural Heritage Objects Repository
Developing Software
Cultural Heritage Objects Repository

7. Building Accessibility in from the start
Slide Title
Building Accessibility in from the start
Accessibility is a foundational philosophy from day one.
Informed decision to build from framework rather than solution bundle.
Front-end AND back-end accessibility
Staff need an accessible interface too.
Universal design and progressive enhancement.
During MVP development, minimal JavaScript.
Will add additional JavaScript during 1.x development.
Valid and semantic coding, Unicode, and knowing the proper usage of ALT and ARIA attributes
Regular automated testing with each sprint cycle, scheduled full human testing with Enterprise IT Accessibility Group.
Samvera-based digital repository with Blacklight as the only starting UI.
Evaluated existing Samvera options, like Hyrax and Hyku, and there were accessibility issues with all of them.
Accessibility a priority, required feature from day one. Every incremental release undergoes some form of accessibility testing.
Full testing with EIT Accessibility Group as needed and planned for major releases.
MVP includes minimal/no JavaScript or other fancy UI features to maintain focus on core accessibility for graceful fallback.
1.x development will bring the fancy UI features most users expect.
Universal Design
Staff need an accessible interface too. Don’t focus only on the public side of things.
Not only do we employ all types of people, but anyone can suffer temporary or new impairments.
Temporary disability like a broken arm or hand surgery or failing eye sight

8. Penn State
University Libraries
THANK YOU
Nathan Tallman Product Owner, Digital Collection Repositories; Digital Preservation Librarian