This guide shares practical steps for planning accessible and inclusive events in research software communities. It builds on existing accessibility guidance and highlights extra things to consider when your event includes technical talks, live coding, shared repositories or ongoing collaboration.

It is aimed at event organisers, workshop leads, programme committees and community organisers working in research software.

Aim of the guide

After reading this guide, you should be able to:

• Spot key stages where inclusion should be considered
• Use general accessibility guidance as a starting point
• Design clearer and more accessible calls for proposals
• Plan fair hybrid and remote participation
• Set expectations for accessible technical talks and materials
• Support inclusive follow-up collaboration

Why this guide is useful

There is already good guidance on accessible events in general. The Zero Project Conference Accessibility Guide is a strong place to start. It covers venue access, communication, budgeting and general event planning. You may also find the Software Sustainability Institute’s Event Organisation Guide helpful for general planning considerations.

However, research software events often include extra layers. There may be live coding, technical demonstrations, shared repositories and follow-up development work. In this context, accessibility includes how technical knowledge is shared and collaboration continues after the event.

This guide builds on general accessibility advice and adds practical steps that are specific to research software communities.

Start with strong foundations

Begin with an established accessibility framework such as the Zero Project guide. Use it to shape your planning from the start. Inclusion works best when it is part of the plan from the beginning.

When designing calls for contributions to research software events also consider:

• Does your call for proposals assume people already know the “right” tools or workflows?
• Are you asking for links to code repositories? If so, have you explained how they will be judged?
• Are you taking into account that early-career researchers may have smaller or less polished repositories?
• Are you valuing learning, experimentation and community contribution as well as technical complexity?
• Have you made it clear if talks do not need to present finished or “perfect” software?
• Have you shared simple guidance on accessible slides, demos and shared materials?
• Have you included a section for knowledge expectations, including programming languages or tools?

Calls for proposals in research software often request repository links, previous talks or evidence of impact. These can unintentionally favour people who have had more time, funding or institutional support.

If you request repositories, explain what you are looking for. For example:

• Clarity of documentation
• Openness to collaboration
• Evidence of community use
• Reflection on lessons learned

Make it clear that a small, well-documented project can be as valuable as a large and complex one. If possible, provide an example of a strong submission or a template. This helps reduce uncertainty, particularly for early-career or new contributors.

If your audience is international, programme organisers should also consider time zones and avoid scheduling all key sessions in one region’s working hours

Design for real participation

Many research software events include live demonstrations, coding sessions and hybrid formats. These can exclude people if not planned carefully.

When planning your sessions:

• Ask presenters to use large, readable fonts
• Encourage high-contrast colour schemes in slides and terminals
• Ask speakers to describe what they are doing during live coding
• Avoid assuming everyone has fast internet or powerful hardware
• Share technical requirements well in advance
• Offer browser-based or lightweight options where possible

If your event is hybrid or online:

• Explain clearly how remote participants can ask questions
• Use shared notes or moderated chat
• Avoid making important decisions in side conversations
• Record sessions and explain how to engage later

Design participation so that remote attendees and early-career participants are not treated as an afterthought.

Think beyond the event day

Research software events often lead to ongoing work. There may be new repositories, working groups or collaborations.

Event organisers should set expectations early that:

• Slides and recordings should meet basic accessibility standards
• Materials should be shared in a clearly communicated, accessible location, with information on how long they will remain available
• Shared repositories should include clear README files
• Licensing should be clearly stated
• Decisions and next steps should be written down and shared
• If you expect follow-up collaboration, explain how people can stay involved. Provide clear sign-up forms or contact points. Do not rely only on informal invitations.

Organisers do not need to control every future activity, but they can create fair starting conditions.

Takeaway message

Accessible and inclusive event planning in research software builds on good general practice. It also requires attention to technical communication, hybrid participation and shared outputs.

Set expectations early. Communicate clearly. Make small improvements each time you run an event.

Inclusion is not a single action. It is part of how you design, run and follow up on your event.

Further reading

These resources provide more detailed guidance and can support you in putting these ideas into practice.

Event planning

SSI - Event Organisation Guide

Accessibility

Zero Project - Conference Accessibility Guide

National Co-ordinating Centre for Public Engagement – Accessible and Inclusive Events Guide

Technical events

The Turing Way - Accessibility

Inclusive participation and community building

SSI - Top Tips for Managing Your Open Source Project Community Effectively

About the author

Laura Crawford, Rosalind Franklin Institute.

Find Laura on Github

ORCID: https://orcid.org/0000-0002-3553-7049

Acknowledgements

This guide was reviewed by Patricia Herterich, Chief of Staff at OLS and SSI Fellow.