Digital accessibility is often seen as a compliance issue, but King’s Digital Lab’s experience shows it is deeply rooted in human connection, team dynamics, and strategic thinking. We share our current approach to embedding accessibility within research software projects. Informed by years of learning and feedback, the updated process is designed to be both practical and collaborative, ensuring accessibility is actively considered across software development roles and project phases, encouraging shared ownership across disciplines. To reflect the evolving landscape of accessibility expectations, our work also acknowledges the growing shift in digital-service organisations from treating accessibility as a legal requirement to understanding it as an organisational responsibility shaped by culture, workflow, and sustained team practices.

Our approach is informed by established digital accessibility standards and evolving research on how teams integrate those standards into practice. Foundational guidance such as the UK Public Sector Accessibility Regulations (https://www.legislation.gov.uk/uksi/2018/952/made); the “Making Online Public Services Accessible” campaign (https://www.gov.uk/government/digital-accessibility); WCAG 2.2 (W3C, 2023: https://www.w3.org/TR/WCAG22/); and community-led resources such as The A11y Project (https://www.a11yproject.com/) and AbilityNet (https://abilitynet.org.uk/accessibility-services/what-is-digital-accessibility) continue to define the baseline expectations for accessible public interfaces. These sources clarify what accessibility is and why it matters, but they also highlight the limitations of viewing accessibility solely as compliance. To better understand accessibility as a continuous, team-based practice, we also draw on empirical scholarship. Bi et al. (2021) demonstrate that developers frequently struggle to apply accessibility guidelines in real-world contexts due to organisational barriers and unclear responsibilities. D’Agostini and Feitosa (2022) show that Agile environments often deprioritise accessibility unless structures for accountability are deliberately embedded. Guerette & Savidis (2012) further argue that accessibility requirements are rarely integrated systematically across project stages, creating recurring gaps between intention and delivery. Together these sources reveal a clear gap: accessibility frameworks rarely address how multi-disciplinary teams in research-software settings distribute, negotiate, or sustain accessibility work. This gap directly aligns with our aim to reframe accessibility as collective responsibility within an SDLC-aligned workflow, informed by shared documentation, roles, and cross-functional collaboration.

In 2023, we formed a dedicated accessibility team involving a designer, engineer, and project manager to lead a procedural shift. The approach builds on lessons learnt from previous efforts and is structured around our Software Development Life Cycle (SDLC). It is supported by shared documentation and visual artefacts, with stages aligned to clearly defined roles and responsibilities. This team was created not only to strengthen accountability but also to address the persistent gap, identified in both our internal reflections and the literature, between knowing accessibility standards and operationalising them in complex research-software environments.

The process was trialled on active projects to test its usability, refine documentation, and identify areas for improvement within ongoing project workflows. This iterative rollout ensured the approach stayed responsive to real team needs, while encouraging open feedback and continuous refinement. We focused on building a process that promotes engagement, adaptability, and sustained momentum over rigid compliance. This emphasis on iteration reflects insights from research, which consistently notes that accessibility is most durable when incorporated into feedback loops rather than treated as a late-stage audit.

The poster outlines key principles and elements that shaped our process, offering RSE teams opportunities to reflect on, adapt, or build upon them in their own contexts. Our process begins at pre-project stage by identifying initial accessibility requirements followed by more detailed scoping carried out with the project team when the project starts. Assessments and fixes are integrated continuously during development. Fixes are documented in GitHub; unresolved issues, tools, and methods are recorded in the accessibility statement when needed. By incorporating these steps directly into existing SDLC structures, we aim to normalise accessibility as routine project practice rather than specialist intervention.

We welcome feedback, collaboration, and insights from others exploring inclusive, process-based strategies for accessibility in technical and research-focused environments. Our goal is to foster accessible outputs through approaches that are inclusive not just of users, but of the research software teams that create them. By aligning academic insight, sector standards, community practice, and internal reflection, we hope to demonstrate how sustainable accessibility emerges not from isolated expertise, but from collective responsibility embedded across an organisation.