Keywords

1 Introduction

Computing systems designed for people with disabilities are continually evolving through the research and development (R&D) of assistive technologies and improved design practices. At the forefront of these R&D endeavors is the creation of cloud-based accessibility technology, led by the international Global Public Inclusive Infrastructure Consortium (GPII) [1]. With cloud-based accessibility, people have the ability to automatically customize an application to their personal needs. This “autopersonalization” can operate on any computer, including mobile computing devices. Therefore, people can have the experience of personalized accessibility on any public computer, including a mobile device, as if it were their own. As the technology for this cloud-based accessibility grows, research is being conducted to evaluate its applicability in various domains [2–5].

Recognizing the importance of reducing barriers to voting for people with disabilities the goal of this research was to perform an evaluation of cloud-based accessibility in the voting domain. GPII has not been extensively evaluated in the civic realm; applying it to the voting domain permits evaluation of public use by a wide population of people with a range of abilities. The foundation of this next generation voting research is a mobile ballot-marking application prototype, referred to as the Next Generation Voting Platform (NGVP). The application was designed to allow voters to mark a blank ballot using cloud-based accessibility to personalize its presentation. Although discussed here, as the demonstration of cloud-based accessibility in voting was the goal of the project, this paper does not fully delve into the ownership or operation of the GPII cloud, nor into the security concerns that may arise when voters cast their vote at the polling place.

2 Background

2.1 Voting, HAVA, and the VVSG

Voting system technology is continuously evolving, along with the voting process itself. Over the past decade, technology in particular has changed drastically due to the passage of the Help America Vote Act (HAVA), reforming the voting process throughout the nation [6]. Through HAVA, the U.S. Election Assistance Commission (EAC) was formed, in part, to develop technical guidelines for the design and certification of voting systems [7]. Since the creation of the 2005 Voluntary Voting System Guidelines (VVSG), NIST and the EAC have published additional materials to support those guidelines [8]. The VVSG and supplemental reports provide recommendations (e.g., for human factors, accessibility, privacy, security, software) for various voting systems (i.e., electronic and paper-based systems). As voting systems, concepts, and processes evolve to incorporate various technologies (e.g. commercial-off-the-shelf (COTS) hardware), it has become necessary to update the original standards.

The VVSG in use today does not address the usability and accessibility of mobile computing devices, COTS hardware, or cloud-based services. As such, this work may have considerable implications for future standards. Certain aspects of the interface of mobile COTS devices vary greatly from the stationary systems on which the current guidelines were based, particularly in size. Similarly, the interaction using accessibility features local to the computing device differs from those afforded by the use of cloud-based accessibility. While this paper does not make recommendations for new guidelines, it is a building block in the conversation about next generation standards.

2.2 Global Public Inclusive Infrastructure (GPII)

The Global Public Inclusive Infrastructure, or GPII, is a projectFootnote 1 started in 2010 that aims to simplify the development, delivery, and support of accessible technologies. The GPII infrastructure supports a “secure personalization profile system that allows users’ access features to be automatically invoked and set up for them,” through the use of cloud computing technology. Using the GPII cloud, users will have the ability to automatically configure any computer or information and communication technology (ICT) to comply with the assistive techniques and technologies needed [1].

GPII is a concept that is still in the development stage. The goal of GPII is to ensure that all people, regardless of ability or economic resources, have access to the internet, its information, and services. However, because this concept is scaled for global development and deployment, it requires the coordination of national infrastructures, funding, and operation. In 2011, The European Commission provided funding for the Cloud4All program with the objective of developing key technical components of GPII [1, 9]. As GPII and Cloud4All are still in the early stages of the development process, many unknowns exist pertaining to global and national use. Exploring the use of GPII within the voting domain at this point of its implementation is an opportunity to evaluate its potential civic use; however, to facilitate current exploration in the voting domain, the overarching GPII concepts necessary for the development of the NIST NGVP prototype were simulated.

The GPII concept of a “personalization profile system” allows a user to login to a cloud-based system to access their personal profile. This profile, or “Needs and Preferences set” (N&P set), is stored on the cloud and contains characteristics of a user interface (UI) that are necessary for the user to interact with any system without barriers. Using cloud-based accessibility-enabled computing system, a user can log into their cloud profile and interact with an interface that is automatically adjusted to his or her needs (as specified in that particular user’s N&P set). Settings of N&P sets fall under display, control, or content categories, and include visual, auditory, and physical interaction features [10]. This autopersonalization – the customization of the UI based on the user’s N&P set – was simulated for the NIST NGVP.

3 Design and Implementation

3.1 Accessible Voting Use Case

There are many variables to consider when formulating use cases for accessible voting with mobile devices. The first of these is the method by which voters will cast, or submit, their ballot (independent from making their ballot selections). Due to unresolved security issues prevalent in internet voting [11], the use cases presented here do not suggest that voters cast their ballots over a network. Rather, the two main methods for casting ballots for this mobile accessible voting use case are via mail-in or in-person at the voter’s polling place. For voters who live in jurisdictions that do not support mail-in voting, they can scan their completed ballot (or ballot representation, e.g., a barcode) at the polling place.

The second consideration is the location where the ballot marking will take place. Given the mobility of the voting device, voters could conceivably mark their ballot from anywhere. For the purposes of this project, we consider “anywhere” to be the voter’s home, an assisted living facility, a public place (e.g., a library), or a traditional polling place.

The final variable to consider is the ownership of the mobile device. Is the device owned by the voter, an official election entity, or an alternate public or private entity? This has a direct impact on the nature of the accessibility of the device. If the device is privately owned, the accessibility features can be local to the device, configured according to the user’s exact needs (potentially eliminating the need for cloud-based accessibility). However, a downloaded blank ballot is required for privately owned devices (since they are not pre-loaded). If the device is owned by an election jurisdiction, cloud-based accessibility would benefit the voter; since the device is shared between many voters, there is a greater need for autopersonalization. In this case, blank ballots can be local to the device (eliminating the need for blank ballots to be downloaded), but voters’ N&P sets would need to be downloaded to configure the interface.

A wide range of use cases can be constructed given the aforementioned variables and the personas described in the Background section. The following factors make up the cloud-based accessible voting use case.

  1. 1.

    Voters can mark their ballot in any location.

    1. (a)

      Voters must have internet access to download the ballot and to download their accessibility needs from the cloud.

  2. 2.

    The mobile device can have public or private ownership.

    1. (a)

      Regardless of public/private ownership, the application will retrieve the voter’s accessibility needs from the cloud. For privacy reasons, although it is currently an available option, voters should not be required to electronically save their ballot to an external device, nor to electronically send their ballot for future printing.

    2. (b)

      If the device is publicly owned, there must be access to a printer to print the completed ballot or a representation of the completed ballot.

    3. (c)

      If the device is privately owned, the voter has the option either to scan the printed completed ballot or a representation of the completed ballot, or to scan an electronic form of the completed ballot at the polling place.

  3. 3.

    Ballot casting is either done via mail-in or in-person at the polling place.Footnote 2

    1. (a)

      Voters who cast at the polling place (by scanning a printed paper or an electronic form) must confirm, or verify, the accuracy of their completed ballot prior to casting, via a verification system.Footnote 3 Therefore, polling place verification systems must be accessible, implementing cloud-based accessibility in one of two ways. (1) Verification systems at the polling place have the capability to connect to the cloud to download the voters’ accessibility needs. This requires a network connection. (2) The ballot (or ballot representation) scanned at the polling place includes UI specifications, based on the voter’s GPII N&P set with which the ballot was originally marked. This bypasses the need for a network connection for the verification system.

    2. (b)

      For mail-in voting, voters print their completed ballot, then mail it to the elections office. If the mobile device used is owned by the election jurisdiction, there should be an accessible method for the voter to verify the printed ballot prior to mailing (in one of the two methods mentioned in the previous bullet). However, no such verification system exists if the voter is using a privately-owned device, or a device owned by an alternate public entity.

3.2 The Next Generation Voting Platform (NGVP)

Voting Process. The introduction of mobile devices into the voting process presents a multitude of methods for voters to vote and cast their ballots. For voters with disabilities, this adds flexibility to a once static voting process. The majority of voting jurisdictions in the U.S. require voters to complete the entire voting process – sequentially from voter check-in to ballot casting – in centralized polling places. This static process poses a challenge to some voters with disabilities because of the duration of their required physical presence at the polling place. Additionally, many of these polling places have a limited number of accessible voting machines – which are not capable of being fully customized to meet the wide variety of voters’ needs.Footnote 4

The use of mobile devices and cloud-based accessibility during the voting process would yield a more flexible experience for voters for various reasons. The most obvious benefit is that the use of mobile devices allows voters to mark their ballot anywhere, reducing the time required to be physically present at the polling place. Another major difference is that voters with disabilities would have the ability to vote on any device and have that device auto-configured to meet their personal needs.

The NGVP has built upon the traditional voting process by incorporating mobile devices and cloud-based accessibility. The complete NGVP voting process can be summarized as follows, with steps one through four anywhere and steps five through eight at the polling place:Footnote 5

  1. 1.

    The voter establishes desired accessibility configuration based on features stored in the cloud.

  2. 2.

    The voter downloads a blank ballot.

  3. 3.

    The voter completes the ballot.

  4. 4.

    The voter generates their completed ballot (or ballot representation) for casting.

  5. 5.

    The voter checks-in with the poll worker at their polling place.

  6. 6.

    The voter scans their ballot (or ballot representation).

  7. 7.

    The voter verifies their ballot.

  8. 8.

    The voter casts their ballot.

Design. The NGVP was implemented based on a design for the use case presented in the Accessible Voting Use Case section. The NGVP is designed to use COTS mobile devices as electronic ballot marking web-based interfaces in which the voter downloads and marks (completes) a blank ballot anywhere. The verification and casting of the marked ballot occurs separately at their polling place (unless mail-in voting is permitted). Figure 1 illustrates the NGVP design. From any location with internet access, the mobile device accesses the GPII cloud for the UI configuration, and the Ballot cloud to download the blank ballot.Footnote 6 After completing the ballot, the voter brings the device, or optionally printed ballot representation, to the polling place. At the polling place, a scanner or code reader captures the ballot selections and transfers them to the ballot verification system. The ballot verification system may retrieve the voter’s UI configurations from the GPII cloud or from the scanner/QR code reader (optional; shown as dashed arrow in Fig. 1). Once verified by the voter, the ballot is cast as a part of the verification system or a separate vote tallying system. The next two sections describe the interaction with the GPII cloud.

Fig. 1.
figure 1

NGVP design diagram

Full size image

Ballot Marking and Cloud-Based Accessibility. The nature of voting – its infrequent occurrence and wide range of voter abilities – requires technology that is easy to use and accessible. Therefore, some voting systems employ a universal design – designing all products, buildings and exterior spaces to be usable by all people to the greatest extent possible [12] – enhancing voting system usability and accessibility for many voters. However, a universal design may not be sufficient to allow all citizens of all abilities to vote. The NGVP goes beyond universal design by incorporating cloud-based accessibility into the development of the tablet-based ballot-marking application. With typical voting systems, a universal design may be achieved by allowing the voter to manually alter characteristics of the ballot interface, such as text size and speech volume. Using cloud-based accessibility – GPII technology – the NGVP provides voters the option to automatically modify the necessary ballot interface characteristics to be more helpful to them.

Thus far, three configurable ballot interface characteristics have been implemented for the NGVP tablet-based prototype: text size, audio volume, and speech rate. The text size feature applies to the visual ballot interface, while the audio volume and speech rate apply to the audio ballot interface. Before the voter loads a ballot, they are presented with a screen to manually adjust these ballot interface settings (see Fig. 2). In the left margin of this screen, below the instructions, are textboxes where the voter can use their existing GPII username and password to login to the GPII cloud to retrieve their N&P set. Once the GPII voter profile information is retrieved, the NGVP interface settings automatically adjust, and the voter will immediately see (or hear) changes to the ballot interface based on the configurations in their N&P set (see Fig. 3). The voter is then able to modify the new settings as needed, or to continue to the ballot with the GPII adjustments. At any point in the following process to mark the ballot, the voter can return to the ballot settings page to adjust the interface.

Fig. 2.
figure 2

NGVP default ballot settings screenshot

Full size image
Fig. 3.
figure 3

Autopersonalized ballot settings screenshot

Full size image

Ballot Verification and Cloud-Based Accessibility. There are two main stages of the NGVP voting process – marking the ballot “anywhere,” and verifying and casting the completed ballot at the polling place (or mail-in). After the voter completes an NGVP ballot, it needs to be cast at their polling place. The conversion of the mobile ballot to a form that is acceptable at a polling place can happen in one of three ways: printing the ballot selections and optional QR code (representing ballot selections), printing a full ballot with selections marked, or saving an electronic rendering of the QR code. At the polling place, the voter has the opportunity to verify their selections by scanning one of these ballot representations into the verification system.Footnote 7

The verification system is the final step prior to casting a ballot. Since the voter will be interacting with this system, it must be accessible. To be consistent with the NGVP ballot marking application, the verification system needs to be “autopersonalization-compliant.” Therefore, the verification interface should allow automatic interface configurations, for which there are two methods:

  • The verification system has an open connection to the GPII cloud, allowing the voter to login with their username and password. (This is most unlikely due to the security issues with internet connections in polling places.)

  • The voter’s ballot interface settings can be transferred to the verification system via the scanned QR code. In this case, the voter would not need to login to the GPII cloud again.

In both of these methods for verification, the system must have an auto-configurable interface.

4 Discussion

4.1 GPII Technical Considerations

As the research and development plans for GPII in the U.S. grow, so too will the potential for GPII to influence the design of new and existing applications.

Infrastructure and Application Design. In order for GPII technology to transition from theory to practice, unanswered development questions need to be addressed.

  1. 1.

    Where is the cloud? The GPII, which will eventually be a collaborative initiative of National Public Inclusive Infrastructures (NPII), must be built [1]. For the NPII to be implemented at the federal level, where will the cloud reside? Will it be solely for use for government services, or will it be open to public and private institutions, organizations, and corporations? Who funds, builds, operates, and maintains the NPII?

  2. 2.

    What type of settings can be configured? Will developers have the capability to adjust settings [10] at the application level, the system level, or both? In an online ballot-marking tool, the application can control its UI, but perhaps not the browser or system settings.

  3. 3.

    Are there potential conflicts in the permissions? There is a permission hierarchy for settings access and use, between the applications and systems on which they run. If a user has multiple profiles on the cloud, one for each level, how is priority assigned?

The responses to these questions may not directly impact the end users, but it will have a bearing on if and how developers will utilize the NPII. In all, although a promising initiative, the practical use of the cloud-based accessibility infrastructure cannot be fully achieved until these unknowns are resolved.

User Accounts. In order to utilize the autopersonalization feature in the NIST prototype, voters can login to the accessibility cloud with their GPII user name and password, possibly leading to the issues of (1) voter inability to recall their GPII credentials, or (2) voters wish to create a new GPII account or profile. Additionally, the NGVP ballot-marking application is not intended to be a portal to the accessibility cloud, but instead, to take advantage of the information stored within it. Therefore, typical account login features such as resetting user passwords or offering challenge questions are not available in the NGVP application. GPII profile initialization and management should be an entirely separate application and process, so as not to cause major interference with the voting process.

Cloud Implications of Hardware and Software Updates. As more organizations and individuals use cloud services [13], general usability issues of cloud access, reliability, and operability arise [14]. Issues include device independence, availability, and consistency. Device independence allows users to access the cloud services from any device at any location. Availability ensures that the user can access the cloud at any time, under any situation. Consistency addresses the fulfillment of user access to all features on all supported devices. These three principles can become major issues if cloud software is updated by the cloud manager (as required), but without proper assurance testing. These access issues may also arise if the user updates their device hardware. Additionally, how would this affect the settings stored in the users’ profiles? With an abundance of mobile devices used by voters, as well as a wide and diverse range of assistive technologies, addressing these types of issues are essential to the success of GPII, within and beyond the voting realm.

4.2 Privacy and Trust

The convenience of autopersonalization comes with a cost – storing personal information on the accessibility cloud. In this case, personal information does not include typical personal identifiable information (PII), such as name, birthdate, and social security number, but rather the preferences and settings catered to an individual. In the design of voting systems, the privacy of an individual is a major design attribute [15]. With cloud-based accessibility, voters may be concerned that they, or their disabilities, may be identified based on the information in their profiles.Footnote 8

Because voting systems require access to retrieve a voter’s settings, it is conceivable that voters may be uncomfortable storing information about their assistive needs.Footnote 9 To clarify, consider a voter with a disability that is not readily visible in public. Any UI adjustment information stored in their profile would be exposed to anyone with access to that information (see previous section on who owns and manages the cloud). For example, a voter with a visual or mild dexterity disability may feel violated if an election official is aware of his or her disability (or feel in danger if this information is disclosed to others) solely based on the interface settings in their GPII account profile. While organizations have been working to address issues of internet related privacy and identity management [16, 17], no one solution has yet gained widespread acceptance.

5 Conclusion

The goal of the NIST project was to examine how cloud-based accessibility could be applied to the voting domain and to investigate how this process might be applied to other domains. In exploring next generation voting processes, cloud-based accessibility was found to have the potential to vastly improve the accessibility of voting system interfaces [18]. Cloud-based accessibility is a promising immediate future research area, one that once important questions are addressed, can have a great impact on elections technology.