Silverchair has prioritized accessibility for years, having designed, developed, and hosted federal government sites that legally required 508 Compliance, such as Patient Safety Network and National Guideline Clearinghouse. Today, AA WCAG 2.1 compliance is instilled into our platform’s codebase, which supports over 1300 journals, 8 million articles, 370,000 proceedings, and 50,000 books. Based on a study by the World Bank, 15% of the world’s population experience some form of disability, so we know how essential accessibility is to our clients and their users.
Our User Experience (UX) Designers work with clients from the beginning of projects on AA-compliant color contrast, font-sizing, and terminology. They also consult with developers on interaction design patterns and the semantic sequence of content in the source code to ensure our products are screenreader and keyboard operable.
Our front-end developers are fluent in the WCAG 2.1 guidelines and use the Perceivable, Operable, Understandable, Robust (P.O.U.R.) best practices. They also use in-browser tools such as the Chrome WAVE extension and Lighthouse while developing.
Some examples of accessibility features commonly employed in the Silverchair Platform include:
However, like any SAAS product, our codebase is like a living organism that is constantly changing and growing, so there’s always the risk that a bug or new feature that isn’t 100% AA compliant makes it into a sprint release. How do we solve for that?
Our Software Quality Assurance (SQA) team runs SortSite testing reports for every new build on the platform and on an as-needed basis.
Example of a SortSite scan
These reports flag any snippet of code that is not completely WCAG A or AA compliant, whether it’s in our platform application code or in clients’ content. We use these reports to fill out VPATs for our clients and write remediation stories, which go into our backlog. Our agile workflow enables us to bring these remediation stories into sprints to continually refine and improve the Silverchair Platform’s compliance.
Example of a JIRA Accessibility Remediation ticket
Once a developer has merged remediated code to our DEV environment, we use human exploratory testing to make sure the flag raised by the scan has been addressed. Accessibility remediation has an added benefit of improving the overall quality of our code and our developers’ happiness and efficiency in working in it.
Example of exploratory testing
Since there’s a lot of available information on Web Accessibility, it’s important to understand the terms, rules, and guides that fall under it.
To assist users who may not have a screen reader, we have partnered with Silverchair Universe partner ReadSpeaker to make our blog content more accessible. The text-to-speech “listen” widget at the top of the page may be used to speech-enable content in over 50 languages.
ASPIRE, a verification service for accessibility statements, lists numerous Silverchair publishers, such as the MIT Press, Oxford University Press, McGraw-Hill, Duke University Press, Wolters Kluwer, and the University of California Press. We are proud to be working with all our clients to make research more accessible to all.
Achieving Web Accessibility relies on best practices as well as some additional work. If these accessibility processes are brought up from the start of product design and development, there are fewer obstacles. It can become significantly more difficult if attempted mid-build, or post-launch. Web Accessibility also relies on EVERYONE on a product team to be on board — from developers, to project managers, to designers, to the client.
Silverchair’s processes and roadmap are geared toward breaking down barriers to entry on all our products, propelling our clients’ content to greater reach and impact.