Technology Report on the Outcomes of the Access App Project

 

Nancy Proctor

Tags

accessibility, admin, API, APP, framework, interface, iOS, mobile, open-source, restful, Roundware, server, UI, voice-over

What is this study about?

This case study reports on the technical outcomes of the Access App project.

Top line summary

The Access App has delivered a “minimally viable product” (MVP) iOS app, including a user interface that is accessible for voice-over users and as a restful Roundware (RW) API and framework for iOS. The robust and extensible RW backend can be used by any developer who wants to add RW functionality to their iOS apps. In addition, the interface to the RW web administration system is being made more intuitive to enable museums to easily set up and add content to their RW app.

About the author

Nancy Proctor was a member of the technical team, advising on the development of the software-based elements of the Access App toolkit.

Narrative

The Access App project aims to develop tools and best practices to enable museums and other cultural organizations to increase accessibility to their collections and exhibitions through providing visual descriptions of objects and displays via a mobile app. The visual descriptions can be provided by the institution or recorded by visitors and other users of the app. The app and other software systems for this project are built on the opensource platform Roundware (RW), which was originally developed by programmer, sound artist, and fellow Access App project team member, Halsey Burgund.

These aims entailed significant developments to the RW platform. Halsey Burgund has led the technical team, with major development support from another Access App team member, the accessibility consultant and researcher, Sina Bahram and his organization Prime Access Consulting, an accessibility firm whose clients include high-tech startups, fortune 1000 companies, and both private and nationally-funded museums.

Originally developed to enable crowdsourcing of app users’ voice recordings, the RW application program interface (API) and framework needed to be updated to more effectively handle the accessibility use cases envisioned by this project. A v2 of the API was developed and implemented for the different iterations of the Access App interface developed in the course of the project. The first user interface was tested with blind users, and known deficiencies in the design’s accessibility were identified. As a result, it was decided that a new user interface design was required. Though this did entail a replication of effort in the app interface design, the additional effort demonstrated that the underlying API and framework can be reused by any developer wishing to add RW functionality to an iOS app: no new user interface or experience design is required.

In a monitored context the final “minimal viable product” (MVP) app has been used to gather feedback and to evaluate the basic concepts and aims of the Access App project: it presents questions to users, captures audio from users, and allows users to select an object in the gallery they want to describe and upload their recorded audio to an audio stream that can be played back and manipulated via the app. The MVP app is not appropriate for distribution to users independent of a guided use experience; rather, it demonstrates the functionality of the source code and best practices learned from the project. The source code can now be used by any developer who wants to add RW functionality to an iOS app without any major changes in user interface (UI) or experience design. In addition, thanks to the Access App work, RW’s web administration system is also more user friendly for museum staff who want to set up and add content to a RW app.

Observations

The Access App project has demonstrated that RW functionality can be incorporated into standard apps without any major changes in UI or experience design. This means that a robust and extensible code set is available to anyone who wants to crowdsource audio, text, images, or—without major further development work—video and be able to play back the user-generated content as a live and continuous stream from the app.

The project also highlighted the importance of content-based accessibility in addition to programmatic accessibility (e.g., it is important to describe images and other visual elements used within the content in an app, as well to have an accessible UI).

What I/we would do differently

The project found itself with too few development resources for the work required. In part, this was because the team decided to undertake a second front-end design and development process, which diverted resources from other work. Ideally, the funding for development projects like the Access App would be flexible enough to allow resources to be reallocated quickly and easily in response to each project’s evolution. This would enable teams to use iterative design processes, making it easier to pivot as testing and feedback lead to new insights. Such a process—similar to those used by Agile and other apps—would have enable the Access App team to optimize its workflow and to more effectively combine its testing and development efforts.

In hindsight, we could have delegated more responsibility and tasks to smaller teams. Such a structure would have sped up the design and approval processes, which lagged because large committees needed to weigh in at each stage.

The key finding of the Access App project, however, is that it is detrimental to spend too much time on the look and feel of the app, at the expense of developing other key aspects of the app. Although it is understandable that the team wanted an optimal product to test with end users in order to derive the data and feedback that are the core value of the project, the end product was never intended to be a fully functional app, but rather a toolkit of source code and best practices that would enable others to build RW-facilitated accessibility features into their own apps.

What I/we would not change

Building on RW has turned out to be a good investment: the platform continues to be used by other projects and organizations and is benefitting from development work and funding sources beyond this project. The extreme simplicity of use – offering a clear choice and interface to recording or listening to contributed content – has also reinforced that RW is a good foundation for building apps to crowdsource verbal descriptions for accessibility.

What I/we would not change

Building on RW has turned out to be a good investment: the platform continues to be used by other projects and organizations and is benefitting from development work and funding sources beyond this project. The extreme simplicity of use – offering a clear choice and interface to recording or listening to contributed content – has also reinforced that RW is a good foundation for building apps to crowdsource verbal descriptions for accessibility.

Conclusions

This project’s key technical contributions to the Access App toolkit include a restful RW API and a robust and extensible framework for iOS that can be used by any developer who wants to add RW functionality to their iOS app. In addition, the interface to RW’s web administration system has been made more intuitive, enabling museums to easily set up and add content to their RW apps. The project also demonstrated that these tools can be implemented in standard apps without any major changes to UI or experience design.  

The Access App MVP is usable by people in controlled test settings: it can elicit feedback for evaluation purposes and perform basic functions, such as capturing audio from users, giving them a question, allowing them to select an object they wish to talk about and upload their audio recording, and hearing the recording as part of a stream from the RW backend.

Although the Access App code base is open-source, it does require further cleaning up and documentation in order to be reusable by third parties without reference to the project’s developers. Moreover, the project’s outcomes speak mainly to in-gallery and exhibition scenarios; more development work is required to serve other kinds of venues.