Are accessible software accountable?: A commentary

ABSTRACT

Accessible software is increasingly important as the incidence of disability continues to increase and the population ages globally, ensuring people are not left behind in the digital revolution. Likewise, there is increased interest in ensuring software is accountable such that it is clear about the information it uses and the actions that it takes. While there have been some agreed-upon definitions for accessible, interpretable, and transparent software, accountable software lacks a universal definition and methodology. We argue that for a software to be accountable, it must also be accessible, interpretable, and transparent, and provide a methodology for developing accountable software.

KEYWORDS:

• computer access
• information technology and telecommunications
• policy and legislation
• standards
• universal design
• usability

As software must be increasingly accessible (Burgstahler, 2008) to allow all people with differing abilities to equally benefit from them, they must also be accountable. In other words, an accessible software is not necessarily accountable, which has been succinctly defined recently in the computer science literature as “the obligation to explain and justify conduct”; (Kacianka & Pretschner, 2021). Accessible software may also not be transparent (Do Prado Leite & Cappelli, 2010). This is defined in the software literature as ‘the disclosure of information being processed by software and the processes which produced the information’ (Do Prado Leite and Cappelli, 2010). In this article, we first provide our motivation for building software that is both accountable (including the need to be transparent) and accessible. We then provide a rationale for our proposed definition of accountable accessible software, given the lack of a universally agreed-upon definition at the time of this writing. We conclude this commentary by proposing a methodology for building accountable accessible software.

Accessible software: motivation

While significant policy (Do Prado Leite and Cappelli, 2010, W3C, 2021) is in place that dictates software accessibility, most programs fall short of several key elements (Kulkarni, 2019), leaving people with disabilities behind. While some software may already provide details about transparency (Do Prado Leite & Cappelli, 2010), there is no requirement nor a mandate for this type of disclosure. Generally, end users are unable to query about the content that describes the data an accessible software uses to perform tasks (Meunier, 2008). Similarly, accessible software are unable to be queried about the accessibility standards they use. Some software describe their compliance level (e.g., WCAG W3C, 2021 2.1 AA) but it is difficult to find this information in a common or designated area of the website and any details beyond the categorization.

The following case study illustrates our motivation for raising awareness of the need for accountable accessible software. Jane is about to graduate from college and has her first in-person interview in a new city. She uses her wayfinding app on her smartphone to identify step-by-step directions for getting from her hotel to an office building that is approximately 3 miles away. Jane is a wheelchair user and as it is a beautiful day, prefers to use her wheelchair for transportation rather than hailing a taxi or rideshare. Jane successfully completes the first few directions without issue until she reaches several sidewalk segments with deep cracks on steep slopes. The street is busy and after some consideration, she decides neither the sidewalk nor the street are safe enough for her to continue down the designated path. She stops at the next corner to identify an alternative pathway from her current location to the office building. Not only is the alternative pathway longer (adding 2 more miles to the trip), but it could have saved her time if she had chosen it originally by following that pathway instead. As a result, Jane will now be late to her interview. Later that day, feeling disgruntled, Jane spends significant time searching the wayfinding app for functions that support accessible pathways for wheelchair users but is unable to query the data it uses, the accessibility standards it uses, or the actions it takes. Jane should be able to use her wayfinding app in an accountable manner, but may also be assisted by novel sidewalk accessibility tools (Froehlich et al., 2020; Sinagra & Solutions, 2020) if scaled or merged with other common navigation systems.

Accountable accessible software: definition

A review of the literature reveals that while software accountability is becoming an important consideration in designing new software (David 2004; Eriksén, 2002; Hutchinson et al., 2021; Johnson 2011; Kroll 2020), and in particular, those based on artificial intelligence (Kroll, 2020) or machine learning approaches (Hutchinson et al., 2021), there is currently no universally agreed upon definition of accountability in software. For this, based on the intention of building software that is accessible and the accessibility features they support, we define accountable software as those that are transparent, interpretable, and accessible. Software transparency is a feature that provides in a clear manner to any interested party (end users and others) what information they use, what standards they use, and what information they compute (Meunier, 2008). Software interpretability is a mechanism by which they should be able to explain the data they use, the standards they use, and the actions they take (Miller, 2019). Accessible software, considered as information and communication technology (ICT) by the Access Board (U.S. Access Board, 2021) and in alignment with Section 508 of the Rehabilitation Act (United States. Department of Health, Education and Welfare. Office for Civil Rights, 1978), must be usable to all people, including those with physical, sensory, and cognitive disabilities. Accountable software, which are transparent, interpretable, and accessible, will allow anyone or any organization to check to see whether they are inclusive, have provisions for diversity, are equitable, and/or are fair.

Accountable software benefits all stakeholders, both expert and non-expert (Kacianka & Pretschner, 2021). Expert stakeholders (e.g., software developers and standards developers) will benefit from accountable software by being able to find the details of their contributions to the final product. For example, policy makers and standards developers will be able to query accountable software to see how their accessibility standards are used in accountable software. Non-expert stakeholders (e.g., end users and lawyers) will benefit from accountable software by being able to identify details of the data and the accessibility standards the software uses and how the actions are taken in the software in an understandable manner.

Accountable software: proposed methodology

We propose a unique methodology, comprised of four phases, to build accountable software: Ontology Phase, Standards Phase, Software Phase, and Interpretability Phase. In each phase, we return to our wayfinding example to illustrate the respective outcomes. The Ontology Phase is the first phase of the methodology where all stakeholders, including end users, behavioral scientists, and practitioners, share their requirements, preferences, and knowledge prior to the software design. An example outcome of the Ontology Phase could be the metadata and the workflows that software developers would need to develop a wayfinding app. The Standards Phase is the second phase of the methodology where policy makers, such as designated government agencies, or other contractors through a request for proposal process, promote and incorporate accessibility standards, such as the Americans with Disabilities Act Accessibility Guidelines (ADAAG), into the knowledge obtained from the previous phase. An example outcome of this phase is the set of accessibility standards to which a wayfinding app must adhere. The Software Phase is the third phase of the methodology where software developers use the outcomes from the previous two phases to design and build accountable software. In the wayfinding example, the accountable software built through this methodology would find accessible routes that can be used by people with mobility impairments. The Interpretability Phase is the fourth phase of the proposed methodology where all interested parties, such as end users, will be able to query what data is used and actions it takes. For example, in the wayfinding app, the user would be able to find out what data was used in finding routes, whether any standards were used, or how the final route was selected. Figure 1 shows these four phases where the process starts with the Ontology Phase and there is a feedback loop between the Ontology Phase, the Software Phase, and the Interpretability Phase.

Figure 1. Four phases of the proposed methodology for building accountable software.

In conclusion, the proposed methodology’s unique features are as follows: facilitating engagements and contributions of all before software is designed; providing software developers with appropriate resources to build accessible software; and allowing query of accountable software by expert and non-expert stakeholders to learn what data they use and how they take actions.

Disclosure statement

No potential conflict of interest was reported by the author(s).