Who makes music software accessible?

Hello, I'm Alex Lucas from SARC, the Centre for Interdisciplinary Research in Sound and Music at Queen's University Belfast. I'm a white man in my forties, with dark but greying hair, wearing a blue shirt and jeans. The slides are in SARC's purple, lime and white, with the Queen's and SARC logos, and I'll read everything on them. They're online, with this script, at noiseguaranteed dot org slash assets26.

This talk, "Who makes music software accessible?", presents our TACCESS paper, "The Qualities of Convivial Tools and Their Relevance to Music Software Accessibility", with James Cunningham, Jacob Harrison, Franziska Schroeder and Andrew McPherson.

Design is speculation. Usability studies are typically small and narrow in scope, as Nielsen and Schmettow discuss, so an hour of testing can't reveal how a product will settle into a complex ecology of people, places and things. Following Maceli and Atwood's vision of a fourth wave of HCI, we cannot fully anticipate how an artefact will be used until it is in use, and requirements keep evolving after release.

So our question: how do blind and visually impaired sound creatives achieve access to digital audio workstations, or DAWs, the software used to record and produce music? And what should design practice learn from this?

Our method. We worked with twenty blind and visually impaired sound creatives, from nine countries, recruited through online communities such as Reapers without Peepers. Participants were producers, composers, engineers and sound designers, from beginner to advanced.

Each two-hour remote session began with a semi-structured interview, followed by a contextual enquiry, in which participants carried out a task of their choosing, such as mixing audio stems, while we asked about their actions.

We used reflexive thematic analysis, following Braun and Clarke. Three authors coded the transcripts, one of whom, James, is visually impaired, so we chose screen-reader-accessible tools for every stage of the analysis.

The analysis identified three gaps. The figure shows them as a path broken at education, information and technology, each spanned by a bridge built by disabled communities.

The education gap: educators often lack awareness of non-visual workflows. As Peter Bosher put it, "There is a lot of goodwill without the backup. Educators just don't know what's feasible"

The information gap: music technology manufacturers give very little information on accessible workflows, so people sometimes buy music software without knowing whether it will work with a screen reader.

The technology gap: interfaces, tutorials and manuals are designed for a normative, sighted user, and describe workflows through visual cues.

Online communities of practice, the slide's heading, bridge these gaps. Their knowledge is co-constituted: members pool experiences of products and keep that knowledge current through use. Following Lave and Wenger, membership includes peripheral participation; some members might rarely post, but still learn from the community. Channels are ad hoc and needs-based, such as mailing lists and WhatsApp voice notes, rather than repositories. And members mentor one another, advocate to manufacturers and build tools, such as OSARA, the extension that makes the Reaper DAW usable with a screen reader.

As Rob Williams said: "The community in general has been very positive on my workflow, because there’ve been numerous things that have changed the way I work now because of a workaround or a little demo someone’s (showed) me"

This leads to a central claim. A DAW is often accessible only with the disabled community's knowledge and labour.

Following Bennett, Brady and Branham, access here is interdependent: it is co-created by users, communities and, sometimes, manufacturers. And, as Branham and Kane found in workplaces, this access work is largely invisible. OSARA's developers are unpaid volunteers, and Cockos, Reaper's maker, benefits from their labour. Sighted users never have to do this work: they receive a functional product at the point of purchase.

To theorise this, we draw on Ivan Illich's Tools for Conviviality. The slide shows an Associated Press photo of Illich, from 1969, on the telephone.

Illich argues that tools pass a second watershed, where they begin to constrain rather than liberate. The digital studio lowered the cost of recording, but it is far less tangible than its analogue predecessor, and making it accessible demands specialist skill and access labour.

His alternative is the convivial tool. Priavolou and Niaros distil three qualities: it is learnable through use; you decide when and where to use it; and it adapts to you. Crucially, conviviality is rooted in community.

From this synthesis, we propose three Convivial Accessibility Design Guidelines, shown as three cards.

First, build accessible ecosystems: the materials that support a tool, such as tutorials and manuals, must be accessible too, and avoid visual cues.

Second, embrace interdependent access: recognise that designers, disabled or not, don't have all the answers, and credit and signpost the disabled community's access work, for example on product websites.

Third, design for designers: treat disabled people as designers, not only users. Reaper shows that low-level extension points, through its software development kit, can coexist with proprietary software. As we put it in the paper, the DAW should be ajar.

To conclude: tools must be malleable in use, and the communities that change them must be supported. We cannot rely solely on accessibility requirements such as WCAG; we need the adage ‘nothing about us without us’ to permeate both design and development, emphasising the pronoun us, as a community of practice.

Thank you, and thank you to our twenty participants. This research was funded by the Arts and Humanities Research Council, at SARC, Queen's University Belfast, with colleagues at Imperial College London.

We would appreciate your feedback, which takes two minutes, at noiseguaranteed dot org slash assets26 slash feedback, the top QR code; the lower one links to the slides and script. My email is a dot lucas at qub dot ac dot uk. I'm happy to take questions.