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 Approach
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:
- Providing text alternatives for non-text content
- Making all functionality of content operable through a keyboard, including a “Skip to main navigation” option
- Careful consideration for readability as it applies to typography, color, and contrast
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?
Accessibility Remediation
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
Terminology
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.
- 508 Compliance: Section 508 of the US Rehabilitation Act states that agencies must give disabled employees and members of the public access to information that is comparable to access available to others. Government-funded information must follow this law and guidelines. There are some differences and similarities between 508 and WCAG, but WCAG 2.0 guidelines are a bit more detailed & higher-standard.
- WCAG: Web Content Accessibility Guidelines (WCAG) are standards set by W3C (World Wide Web Consortium, the organization that maintains The Internet) and are widely considered the gold standards in web accessibility. WCAG line-items come in 3 forms: A, AA, and AAA, with AAA being recommended and A being required.
- VPAT: A Voluntary Product Accessibility Template (VPAT) is a document that explains how digital products meet 508 compliance, helping organizations assess accessibility when doing market research and evaluating proposals.
- Screen readers: Assistive technology that helps users who are vision-impaired navigate websites by programmatically synthesizing speech from web text (think Siri for your entire computer). Screen readers are usually built into operating systems and are available as purchasable apps (e.g. JAWS). Screen readers are one of many assistive technologies.
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.