The Equality, Diversity and Inclusion (EDI) Project is a joint programme between The Academy of Social Sciences (AcSS), its member social science societies and the Economic and Social Research Council (ESRC).
The purpose of the programme is to encourage and facilitate greater awareness of, and actions to support, EDI across member social science societies, by working together to share resources, learning and to maximise the potential to effect real and positive change.
As part of this partnership, AcSS and ESRC have given small scale grant funding to support EDI initiatives and interventions. Social science societies were encouraged to submit bids, either at an individual societal level or as a partnership/consortium of learned societies, to support work to pilot or scale up EDI initiatives or interventions.
“The project goes beyond technical compliance for us. It represents a practical and visible commitment to fairness, representation, and inclusive engagement, helping to move EDI forward not just internally, but across our academic and professional networks.”
The British International Studies Association (BISA) was awarded funding to implement two key aspects of their EDI strategy – improving website accessibility for all users, and monitoring/supporting the diversity of applications to, and awarding of, BISA prizes and grants. In this Q&A, BISA Communications Manager, Chrissie Duxson, discusses the web accessibility stream of the project.
Part of the BISA EDI strategy focuses on publicity and social media presence – working to ensure that core messages (text and visual) reflect and communicate an inclusive organisation, and that outputs are accessible.
When tested through an online accessibility checker, the BISA websites had a score of 72, much below the suggested 85+ to equate to a level AA in the WCAG (Web Content Accessibility Guidelines) scoring system. BISA wanted to bring their websites up to AA standard to allow the accessibility needs of most site users to be met. Around one in five people have a disability (GOV.UK). In 2024 there were approximately 300,000 users of the BISA websites (Google analytics data), meaning we estimated that the project could improve things for up to 60,000 site users.
Whilst we have some web accessibility knowledge within our staff and trustee team, we had already implemented what we could, and were still scoring low on the accessibility checker. We therefore decided we required specialist knowledge.
We chose to work with Agile Collective for a few reasons. First, we knew that they had the relevant expertise within their team. Second, it was Agile who developed the BISA websites back in 2019, and have supported them since. This meant we didn’t need to spend money bringing the consultant up to speed on BISA itself, our aims, the way the websites were designed/built etc. Finally, at BISA our procurement policy encourages the use of local and ethical companies where possible, and Agile Collective is a co-op.
Agile Collective conducted a comprehensive accessibility audit of bisa.ac.uk, conference.bisa.ac.uk, and the events/conference management platform used by BISA (open source) against WCAG 2.12 Level AA requirements, including:
Sitewide elements such as headers, footers and cookie banners were also part of the review. As expected, several areas for improvement were identified to bring the sites up to the WCAG 2.12 Level AA standard.
Whilst the WCAG is a useful benchmarking tool, and gave us something to work towards, it is not always reflective of the needs of real-life users. User testing is essential when improving the accessibility of a website because it provides direct insights into how real users with diverse abilities interact with the site.
Our test users were taken through a series of commonly performed tasks across the BISA websites, and in our events/conference platform. The accessibility issues identified through these sessions were written up to a second issues backlog (our first being the issues identified to meet the WCAG AA standard). These were combined to show us all the changes required.
Our consultant had previously worked with Digital Accessibility Centre, whose employees undertake user testing on a regular basis. We had therefore incorporated this into our budget at the outset. We worked with four users covering:
“User testing is essential when improving the accessibility of a website because it provides direct insights into how real users with diverse abilities interact with the site.”
First, definitely do the user testing! It’s informative and eye opening.
Second, even if you have accessibility requirements yourself, don’t assume you know what other individuals with accessibility requirements need. I hadn’t realised that some of the accessibility tools that help me, would be another user’s accessibility nightmare and vice versa. There is such a broad spectrum of needs.
Our consultant wrote a testing script to use in the sessions, which ran the user through the most performed website tasks. This was essential for making the most of the time available, but it was also worthwhile to allow the user to explore other things they noticed or wanted to click on. They might move through the site in a different way to what you thought or intended.
Finally, you should record the testing so you can refer back to it, make notes, and have as many content creators from your society attend or watch it back as possible. It’s important to see real users interacting with your site and content.
There are a few things that you can check and implement as a starting point. These are things that we did from the outset of building our websites. For example:
The gov.uk website has an accessibility blog which you can read for some hints and tips.
We now get all BISA content creators to read this WebAIM guide to alt text which explains things in more detail.
I had certainly underestimated the amount of time that would need to be invested in the project by the BISA staff team. I had allocated all but a small amount of the funding to the consultancy work/user testing, but in reality there was a lot of project management time needed, more content issues than anticipated (content issues had to be sorted by the internal team rather than the consultant team), and time needed for reviewing and testing the updates to the websites.
As someone who requires closed captioning for online meetings, TV etc, I also struggled with processing/understanding the user testing sessions where testers used screen readers or tools like Dragon. These made the captions come through with several audio streams mixed – screen reading and voice activation plus the conversation between the test leader and user – so it was hard to follow. However, it was a good insight into how users probably feel when they can’t access parts of websites!
“A more accessible website signals that we welcome and value diverse users – another goal in our EDI strategy.”
There was only a finite amount of budget to use on the project, and we wanted to make sure we spent it on the things that were most important to achieving the project’s objectives. We therefore categorised the changes needed in the ways you have described. Generally, the ‘now’ tasks were essential for our two main websites to meet the WCAG AA standard, and the ‘next’ and ‘later’ ones weren’t. The majority of ‘next’ and ‘later’ issues were also considered to have the least impact on users, or were identified within our events/conference software – which was not considered ‘in scope’ as part of the funding awarded.
Having an overview of the size of each task was useful for estimating how long it might take, and in turn estimating how far the budget would go.
There are five remaining WCAG AA failures which we were unable to resolve within budget. We have however, noted these in our new accessibility statement. This means users know at the outset what things they might not be able to access, meaning they don’t waste time trying and can access help from the BISA team instead.
We made it through most of the ‘now’ categorised changes – in particular all those ‘now’ tasks that were WCAG failures. The outstanding ‘now’ issues, and the ‘next’ and ‘later’ tasks give us a starting point should we be able to carry out more work at a later date.
The remaining issue which will have the most impact on our website accessibility is our conference management system, Indico. Whilst undertaking this project, it became clear that the events/conference platform provides poor accessibility, and that future work may be required in this area. It is an open-source product so there is scope for customisation, but currently no budget. We would also have to anticipate the knock-on effect of customisations as they can cause other parts of the system to break. In the meantime, it’s useful that we are aware of the challenges users may face.
By making the websites more accessible, we are ensuring that users with a range of needs – such as visual, auditory, motor, or cognitive – can more easily access information, participate in activities, and engage with our content. Removing digital barriers ensures that all users have the same opportunity to benefit from our resources.
A more accessible website signals that we welcome and value diverse users – another goal in our EDI strategy. The project goes beyond technical compliance for us. It represents a practical and visible commitment to fairness, representation, and inclusive engagement, helping to move EDI forward not just internally, but across our academic and professional networks.
Going forward we have several plans. In the short term we will share guidance with all content creators on the site to help maintain the standard we have reached. In the medium term we hope to raise awareness of web accessibility as part of digital inclusion, and as a core component of social responsibility through knowledge sharing initiatives such as this. In the longer term we want to work on the remaining WCAG issues, and other issues raised by users in the testing. We also hope to have the resources to work on other areas of digital inclusion, such as providing captions as standard for our journal video abstracts, and providing resources in multiple languages.
We worked with our consultants, Agile, to put together an article on how to draft an accessibility statement, which we hope will be useful for other social science societies, particularly if they know there are web accessibility issues they are unable to fix. I also linked to some useful alt text guidance in Q7 above.
I would be happy to email or meet virtually anyone who is interested in finding out more. Please email office@bisa.ac.uk and address your emails to Chrissie Duxson.