Last week we convened for the second online TICTeC Civic Tech Surgery, our hands-on programme for fixing some of the prevalent problems in civic tech.
Each TICTeC Lab begins with a public discussion on one topic area affecting the civic tech community. Interested parties can then apply to take suggested ideas forward in a smaller working group, building solutions with the aid of a grant.
In our second Surgery, the discussants examined how to make civic tech more accessible to all: what are the barriers to accessing the tools and services we make, and despite the best of intentions, have these barriers been somehow baked in to our ‘tech for good’ practice?
Bringing their experience and a diversity of international perspectives to the conversation were Mark Renja of Code for Africa; Laura Nelson-Hamilton from Public Digital; Oluseun Onigbinde CEO of BudgIT Nigeria, and Bonnita Nyamwire of Pollicy.
Notes from the meeting can be seen here, as well as the full recording of the session here and a transcript here, but we’ll summarise the main points here.
A summary of the issues identified during the chat and by the audience.
A lack of user-centred design practices Civic tech is often built before there is a full understanding of users’ needs. Users aren’t involved in the planning or during the build, still less do we engage with people who might have extra accessibility needs.
Inhouse culture There’s often no structure within civic tech organisations that ensures that accessibility is built in from the beginning of every project – it’s often seen as something to bolt on at the end. And there’s nothing to ensure that the small changes to our working methods that have a large impact on those trying to access our services are adhered to over the years, through staff turnover or organisational growth.
A lack of expertise Civic tech teams are often small and may not have accessibility knowledge inhouse. It can be tricky, for example, for non-experts to approach a visual interface like maps and make them equally accessible for those with visual impairments.
A lack of funding Funding sources don’t always recognise the necessity for adding time and resource to ensure that a project is accessible. Funders prefer to fund new projects than to give additional funding to an existing one which might allow more work that would make it accessible.
Differing needs Audiences may have access to (or no access to) a diversity of platforms, or speak a variety of languages. We generally assume a level of literacy that a large percentage of the population doesn’t have. And those who need our services most might not even be online.
A lack of understanding our users Engagement by those who are struggling to use the service can be misinterpreted as misuse or abuse. If users with accessibility needs aren’t already accessing our tools — because they can’t — it can be hard to identify them and therefore understand which needs we need to meet.
Don’t assume, ask Ensure that solutions come directly from the experiences of people who will use your tech. Involve these people in every step of the build. How can we normalise this?
Online materials Guidance like the Universal Access Guide by Code For All provides a free and open source for developers to learn from. Make your accessibility guidance friendly and approachable, like accessguide.io. Could we find ways to ensure these resources are more widely known about and adopted?
Get buy-in — and start at the top Get the decision-makers on board with the move to total accessibility. Often this is best achieved by showing them the real-world results of making projects accessible, so this could take the form of meetings with users or really compelling case studies.
A companywide change in culture Embrace the idea of designing and building for everyone as one of your organisation’s guiding principles. Make a guiding document for the entire organisation that informs how everyone thinks about and approaches accessibility. One way to encourage this might be to provide a template.
Utilise pictures Like IKEA instruction manuals, don’t use text where you can use visuals. Employ illustrators to make attractive and easy to understand interfaces. Could one solution be to collaborate with an existing database of illustrators?
Begin with your own colleagues Run an anonymous survey to find out how many staff are disabled and have issues with online tools: this is a powerful way of showing where you already have gaps internally, which can really bring home what a lack of accessibility means. Might we spin this out to a sector-wide survey?
Share figures Try to educate your peers on disability stats so they can grasp the scale of the problem.
Coding that instills change So much of accessibility is optional. That shouldn’t be the case. Build it in. For example, if you’re coding up a website, make it so that people can’t add an image without filling the ALT field in.
Seek to educate funders about accessibility and when applying for new funding, ensure that accessibility is part of the scope. Encourage funders to insist on accessibility being a consideration in every application. Could we identify which funders already consider this a priority and share that with the community?
Consider translation and audio Even automated translation can help widen the accessibility of your materials. Can we experiment with audio based access to information?
Building connections If we can’t do it all, can we provide a means of connecting civic tech companies with organisations that can help?
An accessibility developer corps: a list of software developers with experience in making sites and tools accessible, available for hire and volunteering.
See what’s already been done Identify best practice in other civic tech projects which are accessible and broadly used, whether that’s inherent or accidental.
Start by making events (online and IRL) accessible Include captioning, sign language, transcripts provided afterwards. Make sure videos (both prerecorded and live) have subtitles.
Some of this discussion also took place on Padlet and you can see more ideas there.
We are now inviting people to join the working group (aka Action Lab), which will comprise up to 6 people who are keen to further develop solutions together, for the benefit of the wider civic tech community.
To keep an eye on this progress, and to know more about the next Surgery, see the TICTeC website or sign up for email updates.