User Interfaces on Crossref

Mission Accessible: building better user interfaces for everyone

Lena Stoll — Thu, 21 May 2026 00:00:00 +0000

Today is Global Accessibility Awareness Day, and accessibility has been on our minds lately. We’ve recently completed an internal audit of all our user interfaces, and have added a new accessibility page to our website, where you can find the accessibility documentation that we put together as part of the audit.

Why accessibility matters

Of course we want to keep the barriers to participation in Crossref as low as possible for users with various disabilities. But also, more accessible tools work better for everyone. A person’s access needs can change really quickly: even if you consider yourself to be relatively able-bodied, you are only one minor inconvenience away from at least a temporary disability. All it takes is some dazzling sunlight hitting your eye or your phone screen, or perhaps your dog going after a rabbit in an awkward direction while you are holding the lead (ask me how I know!) - and before you know it, you will be relying on accessibility features to navigate the digital and/or physical world for a while.

An accessible user interface is one that you can navigate and interact with by various methods, including a mouse or touchpad, keyboard, screen reader, voice control, and other assistive technologies. It can be used on various screen sizes and supports zooming in or out without losing any content or functionality. It has sufficient colour contrast, doesn’t flash fast-moving images at you, and has a clear structure that can be understood by both humans and machines.

Where we are today

It is worth mentioning that we didn’t only start thinking about accessibility when we started tackling the full audit of our user interfaces in March 2026. For example, Patrick Vale has previously written in this blog about a browser extension he has created to improve the accessibility of DOI links anywhere on the Internet. And we have known for a long time that there were accessibility gaps in many of our tools, but we didn’t have this centrally documented anywhere.

When we did begin testing all our interfaces for compliance with level AA of the Web Content Accessibility Guidelines (WCAG 2.2) as part of the audit, we knew that some of what we would find was not going to be pretty. In the 26+ years of working with and for the scholarly community, Crossref has built countless tools and reports to offer to members and users, many of which we still maintain today. These are often decades old and have been built in a way that makes it virtually impossible to make them more accessible without rebuilding them entirely. So we know that we will continue to have accessibility gaps for the foreseeable future, but at least now we have a better idea of the scale of the challenge.

It’s also not all doom and gloom: more recently created user interfaces, such our new Metadata Manager, performed much better in the audit than legacy alternatives such as the web deposit form. We found a similar trend when looking at our report interfaces. To illustrate this, compare what happens when running the axe DevTools extension for Google Chrome on a member’s participation report - this is a user interface that was completely re-implemented in 2025. Doing this brings up 26 issues:

Meanwhile, the browsable title list, which has completed a few more trips around the sun, has 254 issues listed:

Beyond WCAG

If you’ve read this far, I hope you are convinced that accessibility is more than just ticking boxes on a conformance report. But especially for a global community like ours, there are other, less technical barriers to participation that we have to consider. For example, language is a major accessibility factor: much of what we as Crossref staff write and say is in English. When we host community events, we enable captions, and we try to leave space for these captions at the bottom of our slides.

We have also started experimenting with simultaneous interpretation during our online events, such as our recent project showcase event for the 2026 metadata sprint in São Paulo. You can find recordings of this event in Spanish, Portuguese, and English on our YouTube channel to see the promising results of these efforts.

What we are working on next

We are currently addressing the accessibility issues identified in our audit of the Crossmark service. Many Crossref members have implemented the Crossmark button and pop-up on their own platforms and websites, so we thought this was a great place to start the remediation efforts following our audit.

We are also in the process of redesigning our main website, www.crossref.org, following an information architecture review completed in 2025. Making changes to the design and navigation of our website will be the perfect opportunity to make our content not just more discoverable and more understandable, but also more accessible.

Clearly there is even more to be done, so watch this space for more updates on our accessibility roadmap and improvements. And if you have first-hand experience of using Crossref services and interfaces with assistive technologies, or you have other input or feedback you’d like to share, leave a comment below or start a discussion in our community forum.

References

Vale, P. (2025). Enhancing DOI Accessibility for All Users. Crossref. https://doi-org.pluma.sjfc.edu/10.64000/pp4rw-mtv44
World Wide Web Consortium (2024). Web Content Accessibility Guidelines (WCAG) 2.2. Retrieved May 8, 2026, from https://www.w3.org/TR/WCAG22/
Montilla, L. & Mahomed, R. (2026). Voices from Crossref Metadata Sprint in São Paulo. Crossref. https://doi-org.pluma.sjfc.edu/10.64000/a5qzf-k1738
Stoll, L. & Korzec, K. (2025). Request for proposals: Crossref website information architecture review. Crossref. https://doi-org.pluma.sjfc.edu/10.64000/058mr-k3s56

Enhancing DOI Accessibility for All Users

Patrick Vale — Mon, 28 Apr 2025 00:00:00 +0000

2025 Update

In 2022, we set out to update our DOI display guidelines with the intention to adopt the proposals in 2025. It’s important to note from the outset that we are not mandating any immediate changes to the DOI display guidelines. Instead, we are working with our community to co-create a solution that addresses the diverse needs of all users, rather than imposing technical changes that may not suit everyone.

Background

DOI links are the lifeblood of scholarly communication. They’re the canonical identifiers that enable researchers to find, cite, and assess academic work. In essence, they’re stable, reliable, and easy to use—provided you can see them. But what happens when a user can’t rely on visual cues?

The Accessibility Challenge

For users of screen readers and other assistive technologies, the full value of a DOI link can be lost. While sighted users benefit from the context surrounding a DOI link—such as the title, abstract, and other metadata—screen reader users often hear just the bare URL. This means they might not know what content the DOI link represents, leading to confusion and a diminished browsing experience.

The problem is compounded by the technical nature of DOI links. Being URIs (Uniform Resource Identifiers), they don’t naturally lend themselves to the same accessibility techniques as standard URLs. When we attempted to tweak DOI links directly, every change that improved accessibility for one group inadvertently hindered another. Whether it was a WCAG (Web Content Accessibility Guidelines) rule or an ARIA (Accessible Rich Internet Applications) attribute, a solution that worked in one area would break in another.

A Community-Driven Approach

Realizing that a one-size-fits-all fix wouldn’t work, we took a different approach - one that involved the community from the outset. After consulting with early adopters and attending an insightful session with the JATS4R accessibility group, it became clear that the answer lay in experimentation and iteration. Rather than modifying the DOI display guidelines immediately, we are developing a tool that enhances the user experience without disrupting the current standards.

It’s worth noting that this solution places the responsibility on the end user rather than on publishers and platform providers. However, by doing so, users can have a consistent browsing experience regardless of the platform they use to access scholarly content. This approach also serves as an important stepping stone toward a future publisher-provided solution—be it via accessibility-focused JavaScript or a mandated dual-link implementation—and any efforts to recommend or mandate such changes will benefit greatly from concrete evidence of the effectiveness and scalability of this approach.

Introducing the DOI Accessibility Enhancer

First demonstrated at the recent Crossref Annual Meeting, here we share our DOI Accessibility Enhancer browser extension. Available now on the Firefox Add-on Store and the Chrome Web Store, this extension is designed to improve the experience of DOI links for screen reader users without altering the default behavior for sighted users.

How It Works

Scanning for DOI Links: The extension scans any webpage for DOI links.
Querying Metadata: Once a DOI is detected, it queries the Crossref REST API to retrieve the title of the corresponding scholarly work.
Enhancing the Link: The title is then injected as a screen-reader–only link. This means that when a screen reader user navigates to the DOI, they hear the title of the paper rather than the opaque URL.
Maintaining Visual Integrity: For sighted users, the original DOI link remains unchanged—visible, clickable, and easy to copy-and-paste.
Highlighting for Testing: An optional feature highlights updated links, making it easier for developers and testers to see the changes in action.

Get Involved

This project is very much a community effort. The extension is open-source, and we welcome feedback and contributions via our GitLab repository, email, or Community Forum. Your real-life experiences and insights will drive future improvements, ensuring that our solution meets the diverse needs of all users.

Try It Out

If you’re using Firefox, head over to the Firefox Add-on Store and install the DOI Accessibility Enhancer today. If you’re a Chrome user, you can find the extension directly in the Chrome Web Store. If you use a screen reader you’ll experience the difference firsthand - and if you don’t, give it a try with VoiceOver enabled (Command-F5 on a Mac).

Together, we can advance scholarly accessibility and ensure that critical research remains discoverable for everyone.

Request for proposals: Crossref website information architecture review

Lena Stoll — Thu, 17 Apr 2025 00:00:00 +0000

We are looking for an organisation to perform an audit of, and propose changes to, the structure and information architecture underlying our website, with the aim of making it easier for everyone in our community to navigate the website and find the information they need.

UPDATE, August 2025: We are partnering with Cazinc and Cactus AI Solutions on this work. Stay tuned for updates on the progress of this project over the coming months.

About Crossref

Crossref is a nonprofit membership organisation that exists to make scholarly communications better. We run open infrastructure to link research objects, entities, and actions, creating a lasting and reusable scholarly record that underpins open science and makes research outputs easy to find, cite, link, assess, and reuse.

Together with our 22,000 members in 160 countries, we drive metadata exchange and support nearly 2 billion monthly API queries, facilitating global research communication, for the benefit of society. Our members include research institutions, publishers, libraries, funders, government bodies, and other stakeholders in the scholarly communications ecosystem.

About the Crossref website

We launched the current website in 2016. A few years later, we custom-developed the current Documentation section, moving from a separate site (Zendesk, and prior to that HelpIQ). We subsequently launched a Discourse community forum and actively encourage self-service there. Despite these efforts, we still answered about 50,000 support emails in 2024.

We use the Hugo static site generator, and all the content, assets, and code are open in GitLab. We have dedicated staging and sandbox branches, and use staging for editing instead of the usual git merge requests, and sandbox for testing more substantial code or navigation changes.

We share the responsibility for editing across the teams, with a page owner/author denoted for each page. Most staff use VSCode for editing; we don’t have or need a CMS. We deploy changes to the live site around twice a week. Several custom shortcodes are in place, such as for tables and displaying related information based on tags, or for presentation elements like highlight boxes or columns. We host (many) images and files directly in the repository, rather than using a CDN. We use Algolia for site search, which was chosen because it can support multiple languages.

Current website structure

There are currently four main sections of the website:

Get involved: this landing page is the most up-to-date with our current positioning and messaging. The section includes how to join as a member and the ways you can participate, obligations and benefits; a welcome page for new members to get started; events and webinars like our annual meeting; special projects or campaigns that need landing pages; fees; programs such as for service providers and ambassadors; global equitable membership; code of conduct; and working groups (which are different from board committees).
Find a service: listing the purpose and value/benefits for each service, such as content registration, metadata retrieval/APIs/Search, Crossmark, Similarity Check, Grant Linking System, and some other quasi-services that require members to develop or enable something, like reference linking or the Open Funder Registry or ROR.
Documentation: following more-or-less our “managed member journey” pathway, this includes getting set up, how to create DOI suffixes, how to select the right tool for content registration, how to interpret the various reports that members receive, what to expect in terms of invoicing, schema library and best practices for metadata sharing incl. guidance on principles to follow and sample XML files to edit. Each ‘service’ then has it’s own documentation section too.
About: governance, including information about our board, committees, and bylaws. Financial information and annual reports. Staff pages, org chart, jobs, and policies incl. employee handbooks. History of Crossref and mission. Under the sub-heading “Operations & sustainability”, there is also detailed information about membership processes such as revocations, managing legal sanctions, member practices, and member offboarding.

Additionally, the website hosts our blog and allows users to sign up for our newsletter, which are two key ways in which we keep our community informed.

Project overview

End goal

We want to allow our community to self-serve with information about what Crossref does, how to become a member, how to use our tools, and how to participate in our programs and services. The Principles of Open Scholarly Infrastructure are central to how we operate, and we want the information about the how, what, and why of Crossref to not only be openly available, but also easy to discover and reuse.

Visitors to www.crossref.org should be offered the information that they are looking for quickly and intuitively. A reduction in the number of help-desk tickets we receive (in 2024 we answered 50,000 of them) would be an indication of an improved self-service website, as would lower bounce rates.

Scope and deliverables

At the end of this information architecture review project, we expect to have agreed on a set of recommendations for tackling the problem statements laid out in the appendix of this document, as well as a plan for how the recommendations should be implemented. This plan will form the basis for an implementation project in 2026. We encourage applications both from organisations who would also be comfortable taking on the implementation project and from those who feel their expertise is specific to the review project described herein.

Specifically, we expect the following deliverables:

Assessment of key user needs (through analytics and/or user interviews incl. editors)
Audit and analysis of current site structure and how it serves key user pathways
Recommendations for content re-architecture, navigation and search improvements
Strategy for taxonomy and/or tagging system
Strategy for documentation site setup
Strategy for information pathways between website, docs, community forum, ticketing systems
Recommended roadmap for 2026 implementation project
Nice to have: Wireframes or annotated sitemaps for future site layout

Problem statements

It is difficult to find information about our services. Even Crossref staff often use search engines to find a page on our website rather than navigating to it or using the built-in search on the website. It’s often not clear whether the information you are looking for is on the “Find a service” page or the “Documentation” page for a given service, and there is no consistent cross-linking between the two groups of pages. There is a search bar prominently placed on the home page, but the search currently only looks for direct matches between the search terms and page contents (with some declensions, stopwords, and fuzziness to allow for typos). We have limited tracking available in Algolia, but can see that in a 7-day span in March 2025, a large portion of searches (78%) returned no results.
It is difficult to navigate our website. The home page contains some quick links to key pages, but they are not very visible. In order to navigate the website from the home page, users have to expand a hamburger menu which takes up the whole page, and are then presented with an overwhelming amount of options. Once users have left the home page, the way they navigate depends on which section of the website a user finds themselves in: all pages have breadcrumbs going back to Home, while only Documentation pages have a hierarchical sidebar. In order to switch between the basic groups of pages (Get involved, Find a service, Documentation, About us), users have to use the global hamburger menu.
Our home page doesn’t do a very good job of explaining who we are and what we do. A lot of real estate is taken up by images and recent news items without much context. Bounce rates from the home page are high (65% as of March 2025).
Our user interfaces and reports are not easily accessible from our website. While we are not a SaaS organisation, there is an established pattern of being able to access an organisation’s services directly from its website (often via a login button at the top right). This is complicated by the fact that we don’t have one single frontend “platform”. In fact we don’t have a single page linking out to the various frontends and interfaces, nor do we have a consistent pattern of linking out to an interface from the documentation page describing how to use it.
Some of the pages and grouping of pages are outdated and don’t reflect our current priorities or ways of working anymore. For example, the Get involved section still features Special programs and Service providers quite prominently, but the cross-functional programs that shape most of our strategic work now (Co-creation and Community Trends, Contributing to the Research Nexus, Open and Sustainable Operations, Metadata Development) are not represented. Find a service strongly suggests we’re a service provider, whereas most of our services are enabling infrastructure, requiring members to build or act on something. Some more recently created pages don’t fit neatly into any of the current groupings: e.g., API Learning Hub can be found under Get involved and in the home page footer, but doesn’t really belong in either. We also have time-limited, special projects or campaigns like the 25th anniversary of Crossref or the Resourcing Crossref for Future Sustainability project, for which there isn’t a great home. Lastly, we want to host additional content on our website in future, such as our own staff publications; instructions on how to find our codebases and how to contribute to them; how to build technical integrations; how to report bugs; and general best practices in scholarly communications (e.g. in the context of our work on the integrity of the scholarly record), which is not really part of the documentation of our services.

Project budget and timeline

We have a maximum budget of $20,000 allocated to the information architecture review project. The projected timeline is as follows:

RFP issued: April 17, 2025
Final deadline for proposals: May 15, 2025
Shortlisted applicant interviews: May 2025
Appointment made: June 2025
Project kick-off: July 2025
Final deliverables due: October 2025

If you are interested in applying but don’t think this timeline is deliverable for you, please contact us to suggest what would be realistic for you or your organisation before applying.

Proposal submission requirements

Proposals, as well as any questions, should be submitted to Lena Stoll by 15 May 2025.

Please include the following in your proposal:

Company background and relevant experience with open-source static sites and mission-driven communications
Case studies or examples of comparable work
Your approach to the proposed project and how you would structure it
Team bios and roles incl. typical timezones
Timeline and milestone estimates
Proposed budget, including breakdown
Proposed cadence of check-ins, communications, milestones, and deliverables
Contact information

Proposal evaluation criteria

We will evaluate proposals based on:

Demonstrated understanding of our mission and community needs
Proven experience designing for multilingual and multinational audiences
Expertise in mission-driven business-to-business communications and information architecture
Quality of previous work and case studies
Value for money