NIME: Creating an Online Ensemble for Home Based Disabled Musicians: why disabled people must be at the heart of developing technology.

by Amble Skuse, Shelly Knotts

Generally the article addresses the use of universal design for software products that are accessible to musicians with various disabilities. Although I am not specifically involved with music interfaces myself, both privately and professionally, it was very interesting for me as an interaction designer to gain more insights into the field. Even if the article is about two different softwares and how they could be improved in order to be more accessible, there is a lot of information and input that can be applied to any other area or digital product.


Within the first paragraphs of the text the authors tackle the term „Disability“. Rather than seeing disabled people as a minority group, who are not able to act the same way non-disabled people can, they want to create a framework with all people and their individual needs working together and being equally included without having one dominant group. This is also a reassuring theme throughout the whole article: Working with the knowledge and experience of disabled people instead of assuming or trying to „solve“ problems for them. One key finding of their research is to bring disabled persons in the process, begin with an equitable approach and make technology more flexible, robust and inclusive.

Universal Design

As previously mentioned the approach of designing for disabled musicians sets its focus on Universal Design, especially on the first principle – „Equitable Use“, which is summed up in following four points:

1a. „Provide the same means of use for all users: identical whenever possible; equivalent when not.

1b. Avoid segregating or stigmatizing any users.

1c. Provisions for privacy, security, and safety should be equally available to all users.

1d. Make the design appealing to all users.“ [1]

Research Goals

The overall goal of this article is to inspire other designers and spread awareness that there is a lot of potential to make music technology systems accessible by providing information and support. As the title of the paper suggests, the project focuses on home-based disabled musicians in order to to provide access for them to collaborate with each other and perform live, both online and at physical events. Particularly important in this project was, that it is „disabled-led“ by putting disabled people in the foreground and actually start with their input instead of sprinkling in on top in the end.


The first stage of the project was an interview phase with 15 home-based disabled musicians from all over the world. They had a diverse range of disabled identities, eg. mobility issues, d/Deaf, Autism, …, however the interviewees were not as demographically diverse as they wished for. For me this was very interesting to see how they handled this by just communicating it open and honest. The following categories of questions were included in the interviews:

  • the approach of making music
  • their personal requirements from music making applications (setup, handling, …)
  • their personal requirements for learning (concentration span, explanation, …)
  • their personal requirements for performance (real time or pre-recorded, duration of performance, …)


At first the project laid its focus on live coding, because it does not require additional hardware like MIDI controllers and can be controlled with various assistive technology like eyegaze or head mouse controllers. Furthermore the bandwidth requirements are reduced in comparison to audio transmission. However the workshop with the target group showed that they are not really into live coding, but would prefer using their existing hardware, which is why the authors decided to shift the focus to audio streaming platforms. Following software tools were analyzed in the paper: Estuary, a live coding interface, Icecast, an audio streaming software, and LiveLab, an open source browser-based interface for sharing video and audio. 


Besides some technical issues with the software there were major political issues in the project. Overall the companies had the feeling that making their products accessible does not fully pay off, so they wanted to restrict the needs to their availability of time and money. One of the main approaches was to make an easy version of the software, which would never be a real part of the main program and therefore not adapted or updated over time. This of course did not match the findings of the interviews at all. Here it was a great concern to put the whole structure and the working process itself above small, surface adaptations. Specifically the musicians wished for a flexible layout, a quick response time, a well documented help, captions in videos, robustness with assistive hardware, accessibility as a part of the main software and including disabled people in the design process. Another main finding was that experiencing being in the community generates and expert knowledge of accessibility, which should always be considered and used in this context. 


Personally I felt that the major issue here was definitely a political one. Companies would rather not make it fully accessible due to financials and since it is not regulated by law or state funded they don’t feel obligated to do adapt their products. „Half accessibility is no accessibility“ was definitely a key statement for me in this article. To end my post on a positive note: I liked how the article stressed the importance of including a broad span of needs in any design work and prioritizing workflows and flexibility in order to be accessible for all. 


Amble H C Skuse and Shelly Knotts. 2020. Creating an Online Ensemble for Home Based Disabled Musicians: Disabled Access and Universal Design – why disabled people must be at the heart of developing technology. Proceedings of the International Conference on New Interfaces for Musical Expression, Birmingham City University, pp. 115–120.

[1] National Disability Authority: What is Universal Design. The 7 Prinicples. In: (zuletzt aufgerufen 4.6.22)