NISTIR 8047

Cloud-based Accessibility for

Voting Applications

Shaneé Dawkins

Sharon Laskowski

This publication is available free of charge from:

http://dx.doi.org/10.6028/NIST.IR.8047
NISTIR 8047 

Cloud-based Accessibility for

Voting Applications

Shaneé Dawkins

Sharon Laskowski

Information Access Division

Information Technology Laboratory

This publication is available free of charge from:

http://dx.doi.org/10.6028/NIST.IR.8047

November 2015

U.S. Department of Commerce 

Penny Pritzker, Secretary

National Institute of Standards and Technology 

Willie May, Under Secretary of Commerce for Standards and Technology and Director 
ii

CONTENTS

Executive Summary............................................................................................................ 1

Introduction......................................................................................................................... 2

Background......................................................................................................................... 2

Voting, HAVA, and the VVSG ...................................................................................... 2

Voter Personas................................................................................................................ 3

Global Public Inclusive Infrastructure (GPII)................................................................. 5

Design and Implementation ................................................................................................ 6

Accessible Voting Use Case ........................................................................................... 6

The Next Generation Voting Platform (NGVP)............................................................. 8

Voting Process............................................................................................................ 8

Design ......................................................................................................................... 9

Cloud-based Accessibility ........................................................................................ 11

Ballot Verification and Cloud-Based Accessibility.................................................. 13

Cloud-Based Accessibility: Application to Broader Domain........................................... 14

The Bunche Electronic Library..................................................................................... 14

Discussion......................................................................................................................... 15

GPII Technical Considerations..................................................................................... 15

Infrastructure and Application Design...................................................................... 15

User Accounts........................................................................................................... 16

Cloud Implications of Hardware and Software Updates .......................................... 18

Privacy and Trust .......................................................................................................... 18

Universal Design versus Cloud-based Accessibility .................................................... 19

Conclusion ........................................................................................................................ 19

References......................................................................................................................... 20

Appendix A – Categorized Voter Personas...................................................................... 22

Appendix B – Components of the Global Public Inclusive Infrastructure ....................... 25

Appendix C – NGVP Technical Diagram ........................................................................ 26
1

Executive Summary

Since its creation, the National Institute on Disability and Rehabilitation Research 

(NIDRR) of the U.S. Department of Education (ED) has supported the development of 

new technologies for enhancing access for people with disabilities. Current research and 

development being conducted by the international Global Public Inclusive Infrastructure 

Consortium (GPII), drawing on work supported by NIDRR, is creating technology for 

cloud-based accessibility. Using this new technology, users of computer systems can 

create personal profiles that specify how computer applications should be configured to 

meet their individual needs. National Institute of Standards and Technology (NIST) 

researchers evaluated the applicability of this new technology for two key applications: in 

voting and in cloud computing applications being developed by federal agencies.

Recognizing the importance of reducing barriers to voting for people with disabilities, 

NIDRR has long supported research and development in voting accessibility. NIST 

conducts research on a wide range of issues relating to voting and voting technology, 

including human factors research on the design and application of voting systems and

assistive technologies for voters with disabilities.

NIST has developed a prototype voting support system with enhanced accessibility 

capabilities based on the cloud-based accessibility work of the GPII. This prototype, the 

Next Generation Voting Platform (NGVP), is a mobile ballot-marking application 

designed such that voters have the capability to use a customized interface to mark a 

blank ballot. NIST researchers investigated the use of cloud-based accessibility as 

applied to voting and applications of this technology to other domains.

The research performed on the NGVP suggests that cloud-based accessibility has the 

potential to be useful to voters when integrated into mobile ballot-marking systems. Via 

the NGVP, a voter can use a mobile device (e.g. tablet computer) to exchange data with a 

cloud-based system to download settings to configure complex ballot interfaces. As the

demonstration of cloud-based accessibility into voting was the goal of the project, this 

report 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. 

Keywords: Accessibility, Cloud-Based Accessibility, Help America Vote Act (HAVA), 

Human Factors, Voting Systems
2

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 

(GPII) [7]. 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 

[1][3][5][12]. 

Part of the research conducted by the National Institute of Standards and Technology 

(NIST) via support from NIDRR under Agreement No. ED-OSE-12-J-0003 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. Voting 

research at NIST is conducive to this work due to its groundbreaking research on the 

measurement and evaluation of next generation voting systems. The foundation of 

NIST’s 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 

customize its presentation. This report presents NIST’s evaluation of this design and 

discusses the application of this process in a comparable domain – the Bunche Electronic 

Library, a semi-public, federal database of records.

Background

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) [8]. In 2002, the U.S. Congress passed HAVA to 

reform the voting process throughout the nation, including funding for the purchase of 

new or updated voting equipment. Through HAVA, the U.S. Election Assistance 
3

Commission (EAC) was formed, in part, to develop voting system guidelines1for 

certifying the compliance of this equipment [20]. NIST was directed by HAVA to assist 

the EAC in leading the technical guidelines development effort.

Since 2002, the EAC and NIST have created several versions of technical guidelines for 

voting system technology, and NIST has published research reports containing additional 

material supporting those guidelines and testing for conformance to the guidelines, 

beginning with the 2005 Voluntary Voting System Guidelines (VVSG) [22]. These 

guidelines and reports provide recommendations (e.g., for human factors, accessibility, 

privacy, security, software) for various voting systems, including direct recording 

electronic (DRE) touchscreens and optical scan paper-based systems. As voting systems, 

concepts, and processes evolve to incorporate various technologies (e.g. commercial-offthe-shelf (COTS) hardware), it has become necessary to update the original standards.

The VVSG2in 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 cloudbased accessibility. While this report does not make recommendations for new 

guidelines, it is a building block in the conversation about next generation standards.

Voter Personas

There are many types of disabilities, which require different methods of interaction. 

People with disabilities may also have multiple disabilities, resulting in a specific subset 

of needs. The Information Technology and Innovation Foundation (ITIF) led a research 

project to develop personas that represent a wide range of voters [23]. Voter personas 

encapsulating this diversity were created to assess the value of new accessible voting 

design concepts. These personas were expanded upon and categorized in 2013 [24]. The 

three categories of personas are listed here, along with a sample persona from each (the 

complete persona list can be found in Appendix A – Categorized Voter Personas):

 

1 These guidelines are standards for certifying voting systems, but are called “guidelines” since it is 

voluntary for the States to adopt them.

2 Although NIST has drafted updated versions of the 2005 VVSG (1.1 and 2.0), voting systems today are 

currently being certified to VVSG 1.0.
4

1. Designing for people who can vote independently

a. “Tasha is a woman who runs her own business. She has been blind since 

birth. She employs a “reader” who reads print materials to her. However, 

she uses a computer independently and prefers that method for accessing 

information.”

2. Designing to reach across the digital divide

a. “Tonie lives in an inner-city neighborhood. She dropped out of high 

school, after her poor reading skills made classes too frustrating. She 

wants to have a voice in her community, but almost missed the last 

election because she did not know where to go vote, and did not know 

how to find the information she needed.”

3. People who need assistance or are in an assisted living facility

a. “Kevin is in a VA rehab hospital, recovering from injuries from an 

explosion in Iraq. He is still learning to use prosthetic arms, work made 

more difficult by difficulty concentrating and sensitivity to bright light. He 

needs help remembering to request an absentee ballot, and how to fill it in 

and return it on time.”

The ITIF personas and persona categories are representative of voter demographics, 

which include, but are not limited to, voters with disabilities (e.g. persona “Amy”– see 

“Designing for people who can vote independently” in Appendix A – Categorized Voter 

Personas). Each of the persona categories represents voters who have real and different 

needs, requiring a diverse set of voting system features. Tasha, for example, is 

technically savvy, but requires a non-visual voting interface. Tonie does not have a high 

literacy level and therefore may find using a voting system with complex instructions 

challenging. Kevin may have difficulties using systems with complex instructions and 

interactions; he also may require a non-manual voting interface with high contrast. To 

meet the needs of each of these personas (and voters not addressed here), traditional3

voting systems would need to have an extensive set of functional capabilities built into 

the system. Rather than modifying current voting systems to individually accommodate 

each demographic, better-fitting solutions may be achieved with cloud-based 

accessibility.

 

3

e.g., Direct Recording Electronic (DRE), or optical scan systems
5

Global Public Inclusive Infrastructure (GPII)

The Global Public Inclusive Infrastructure, or GPII, is a project4started 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 [7].

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

[6][7]. Detailed components of GPII are shown in Appendix B – Components of the 

Global Public Inclusive Infrastructure. As GPII and Cloud4All are still in the early 

stages of the development process, many unknowns exist pertaining to global and 

national use (see the Discussion section). 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

(see The Next Generation Voting Platform (NGVP) Section).

The GPII concept of a “personalization profile system” allows a user to login to a cloudbased 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 cloudbased 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 such as 

font size, background color, speech rate, sticky keys,5and automatic scanning6[10]. 

 

4 GPII is a project created by the Switzerland-based Raising the Floor organization. Raising the Floor is 

made up of over 100 organizations and individuals whose collective goal is “AccessForAll” – accessibility 

and digital inclusion for each individual’s needs [7].

5

“Sticky keys” is a setting that can be used by people who have difficulty holding more than one keyboard 

key simultaneously.
6

This autopersonalization – the customization of the UI based on the user’s N&P set – was 

simulated for the NIST NGVP (see The Next Generation Voting Platform (NGVP)

Section). 

Design and Implementation

This section presents the voting use case considered, as well as the system 

implementation that was designed for this use case.

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 [15], 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-in7or 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 (see the Voting Process section). 

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 – see the 

Discussion section). 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

 

6 Automatic scanning is a selection technique for people who need to use switch input to select an item 

from a list of items (automatically, individually, and sequentially highlighted). 

7 Mail-in voting would only be an option for voters in states that allow vote by mail or that allow absentee 

ballots to be mailed-in.
7

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 cloudbased accessible voting use case for this project.

1. Voters can mark their ballot in any location. 

a. Voters must have internet access to download the ballot and to download 

their accessibility needs from the cloud.

2. The mobile device can have public or private ownership. 

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.

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.

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. Ballot casting is either done via mail-in or in-person at the polling place.8,9

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.

10

 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.

 

8

Ideally, for mail-in voting, voters would be able to verify their printed completed ballot prior to mailing. 

However, no such verification system is in place for mail-in voting.

9 Casting (ballot submission) at the polling place is discussed here, but is outside of the scope of the NGVP 

prototype.

10 Alternately, if a voter would like to spoil their completed ballot, they may discard their ballot or ballot 

representation and use one of the voting systems provided at the polling place to complete a new ballot.
8

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.

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 

selection verification 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.11

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: 

1) The voter establishes desired accessibility configuration based on features stored 

in the cloud.

12

2) The voter downloads a blank ballot.

 

11 Some accessible voting systems have the functionality for the voter to modify certain characteristics of 

the system interface as needed; however, these options are not an extensive list of modifiable 

characteristics.

12 The voter would need to have previously created an N&P set on the cloud (see Discussion section).
9

3) The voter completes the ballot.

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

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

13

6) The voter scans their ballot (or ballot representation).

13

7) The voter verifies their ballot.

8) The voter casts their ballot.

14

 

A diagram representing the NGVP voting process, in comparison with traditional mail-in 

and in-person voting processes, is shown in Figure 1. 

Figure 1 Voting Process Comparison

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 

 

13 For states where mail-in voting is required, or for absentee ballots, steps 5 and 6 are bypassed.

14 For mail-in ballots in this process, the ballot is considered cast when mailed.
10

marked ballot occurs separately at their polling place (unless mail-in voting is permitted –

see Figure 1). Figure 2 further 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.

15

 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 (blue, dashed 

arrow in Figure 2). 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 (shown in Figure 2 as blue arrows; the dashed arrow 

indications an optional connection).

Figure 2 NGVP Design Diagram

 

15 The specific blank ballot downloaded corresponds to the voter’s address. The NGVP prompts the voter to 

enter this information after interface settings have been adjusted.
11

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 [11] – 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 tabletbased 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 Figure 3). In the left 

margin of this screen, below the “Instructions” section, are textboxes where the voter can 

use their existing GPII username and password16 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 Figure 4). 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.

 

16 This feature would only be available to voters who already have a GPII account. Voters would be able to 

create a new account at any time separately through the GPII.
12

Figure 3 NGVP Default Ballot Settings Screenshot
13

Figure 4 NGVP Autopersonalized Ballot Settings Screenshot

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). Cloudbased accessibility as applied to the former (ballot marking anywhere) was described in 

the previous section. This section describes how it can be applied at the polling place.

17

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 code18, 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.

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 

 

17 Verification and casting was conceptualized for the NGVP voting process, but outside of the scope of 

project implementation.

18 The QR code is a representation of the ballot selections.
14

ballot marking application, the verification system needs to be “autopersonalizationcompliant.” 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. The advantages of each method are presented in the Discussion section.

Cloud-Based Accessibility: Application to Broader Domain

Cloud-based accessibility may be useful for other domains similar to the voting domain;

i.e. a domain in which widespread civic service is provided and not limited by location or 

environment. The purpose of exploring another domain is to see if this approach can be 

generalized beyond voting. This section explores cloud-based opportunities for the 

Bunche Electronic Library [18], a semi-public, federal database of records.

The Bunche Electronic Library

The Ralph J. Bunche Library is a research library designed for use by employees of the 

federal government. It is organized under the U. S. Department of State and is only open 

to the public via interlibrary loan. The mission of Bunche Library is “to support the 

research needs of personnel of the Department of State.” [19] The library’s physical 

location is in the Truman building in Washington, D.C, where Department of State staff 

can directly access unclassified and published information sources on foreign relations. 

As electronic access to the Bunche library becomes available, it needs to be accessible for 

the employees of the federal government. In addition, since it may be accessed by the 

general public at-large, it will need to be accessible to a wide range of people. Similar to 

the voting process, the Bunche library will have a resource that can be accessed via the 

Internet (akin to a ballot marker), as well as a resource, albeit not required, accessed at a 

physical location (akin to a polling place). 

The Bunche library could take advantage of the GPII cloud-based accessibility services 

by incorporating them into its electronic access interface. Through the library’s interface, 

users should be able to easily login to their profile on the GPII cloud. A key difference 
15

between the Bunche electronic library UI and the voting system ballot UI is that 

customizable interfaces are already implemented in traditional voting systems; that is, 

voters are able to manually adjust their UI setting within the ballot interface. In the 

NGVP prototype, the source of customization at the time of voting transitioned from the 

voter to the cloud. Typical web interfaces rely on the system or browser settings to 

display the UI. As such, the Bunche Library’s interface will need to adapt to features 

according to the cloud, not the browser (see Discussion section). As the electronic 

library resource is developed, the source of the UI settings need to be dynamic – from the 

browser, or the cloud. Once these underlying changes are made, the process to apply 

cloud-based accessibility is as described in the Cloud-based Accessibility section.

Discussion

In exploring next generation voting processes, cloud-based accessibility was integrated 

into the design of the NIST prototype mobile ballot marking system (NGVP). This 

section summarizes the implementation of the prototype and the issues encountered in the 

development process.

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. The major 

technical implications center on the infrastructure design, and therefore on the design 

requirements of the applications that will use this infrastructure, as well as the cloudbased accounts accessed by the users of the applications. 

Infrastructure and Application Design

In order for GPII technology to transition from theory to practice, unanswered 

development questions need to be addressed. In the most simplified forms: where is the 

cloud; what type of settings can be configured; and are there potential conflicts in the 

permissions?

1. Where is the cloud? The GPII website states that before there is a global solution 

for cloud-based accessibility, National Public Inclusive Infrastructures (NPII) 

must be built. Once the NPIIs are in place, a collaborative initiative could be put 

in place to form the GPII [7]. Cloud technology at its core, as applied to this 

report, is shared storage via a network (see formal NIST definition [13]). This 

storage, though accessed virtually, is a physical entity, needing a location, owner, 

and manager. For the NPII to be implemented at the federal level, where will the 

storage be housed? Will it be solely for use for government services, or will it be 
16

open to public and private institutions, organizations, and corporations? Who 

builds, operates, and maintains the NPII, and how is it funded? 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. For instance, in voting, standards, 

guidelines, and voting system certification are handled at the federal level, but the 

individual states have control over which systems they use and how they 

implement the voting process, and they may set their own standards and 

certification processes. This may also be the case with a federally established 

NPII; the states may want to own and operate their own cloud technologies.

2. What type of settings can be configured? Will developers have the capability to 

adjust settings at the application level, the system level, or both? Currently, GPII 

N&P settings point to the ISO standard for individualized adaptability and 

accessibility – an exhaustive list of both generic and application-specific access 

settings [10]. Will each of these settings be implicitly configurable by the user? 

There are different sets of rule for adjusting the various types of settings. 

Applications (web based or local) will be able to configure certain aspects of their 

UI, but may not be able to access system-specific settings. In an online ballotmarking tool, the application can control its UI, but not the browser settings, and 

not the system settings.

3. Are there potential conflicts in the permissions? There is a permission hierarchy 

for GPII access and use, between the applications and systems on which they run. 

As stated previously, there exist levels of control between applications (websites 

in this case), browsers, and systems. If a user has multiple profiles on the cloud, 

one for each level, how is priority assigned? Settings and configurations have

increased granularity from the system level up to the application level, but how is 

this handled? Are these priority assignments something that should be explicitly 

set by the user?

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

Within voting, the GPII concept introduces questions also about the N&P sets stored in 

the cloud. The NIST prototype is intended to be used by voters on a mobile device. The 

prototype is a web-based ballot marking system, accessible from any location. Upon the 

initial load of the application, the voter can adjust the UI as needed, with the option to 

autopersonalize via GPII’s cloud-based accessibility. In order to utilize the 

autopersonalization feature, voters must login to the accessibility cloud with their user 
17

name and password. At this point, a potential issue arises if the voter cannot remember 

their GPII username or password, or wishes to create a new GPII account or profile. 

Since auto-configuring the ballot interface is not the primary task in the voting process, it 

should not be a major source of distraction from the voter experience. 

The GPII concept views profile handling in two approaches: profile initialization and 

profile management [7]. Profile initialization is intended to be carried out via a personal 

device with existing N&P settings. Users are guided through specific steps to create their 

profile. This process is infeasible for users who wish to create a GPII account when first 

using the NGVP ballot marker on a public device (e.g., library computer or official 

election computer tablet). How can profile initialization be modified so that it can be

accomplished from a public device? Even when developing a solution to this question, 

for voting, one must consider the fact that creating an autopersonalization account profile

can be an arduous task, depending on the voter’s needs. The time needed for profile 

initialization will increase based on the number of features the voter intends to specify in 

their profile. For these reasons, it is an inefficient use of voters’ time to create an account 

at the time of marking a ballot.

19

In contrast to profile initialization, the purpose of profile management is for users to 

change or expand their pre-existing preference settings. This can be done via the profile 

initialization method, or via a separate standalone application. In the voting case, voters 

should not be forced to leave the NGVP application in order to modify their preconfigured GPII N&P settings. Rather, voters would be better served by taking

advantage of the GPII feature that allows for the support of multiple profiles to be created 

under one account. Using this feature, voters can have profiles tailored specifically for 

use in a voting application. In this case, voters would need to modify their “voting 

profile” from within the voting application itself, following the WYSIWYG (what you 

see – hear or feel – is what you get) principle as intended with GPII.

Another issue is if the voter cannot recall their username and password, or for some other

reason has issues logging into their GPII account (e.g., mistyping their account 

information). 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.

 

19 That is, unless the voter begins the voting process well ahead of the ballot submission deadline.
18

Cloud Implications of Hardware and Software Updates

As more organizations and individuals use cloud services, general usability issues of

cloud access, reliability, and operability arise [4]. 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.

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 [21]. With cloudbased accessibility, voters may be concerned that they, or their disabilities, may be 

identified based on the information in their profiles.

20

 

Because voting systems require access to retrieve a voter’s settings, it is conceivable that 

voters may be uncomfortable storing information about their assistive needs21. 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 [9][16], no one solution has yet gained widespread acceptance.

 

20 This is often the case in traditional polling place, where only one voting machine of the many setup is 

accessible, and is used by very few (often one) voters.

21 One alternative to username and password is to use voter registration information, which would indeed 

link the voter needs and preferences to what is typically referred to as PII.
19

Universal Design versus Cloud-based Accessibility

Throughout the NGVP development process, the biggest question raised was the benefit 

of going beyond a universally usable design by incorporating cloud-based accessibility. 

The goal of universal usability is to design a system that can be used by a large 

proportion of the population with a diverse demographic – the “bell” of the normal 

distribution bell curve. Current voting system research emphasizes the use of universal 

designs in ballot interfaces [2] [14] [17]. The interface designs of these systems offer 

vast accessibility improvements over older, traditional voting systems designed statically 

for a specific subset of users. However, HAVA mandates that all voters should be able to 

mark and cast their ballots privately and independently. Is there a fully universally 

usable voting system that can be designed with every voter in mind? Is there a limit to 

the range of demographics that can vote independently with a universal design? 

Applying cloud-based accessibility to voting is a potential solution to this question. A 

single voting system would be able to adapt from its default interface to one that is 

independently usable by any voter, regardless of ability or disability. Then the question 

becomes, how far do you develop a universal design in the base voting system model (i.e. 

the default interface without autopersonalization)? Does the universal design end at 

audio interface capabilities, relying on cloud-based accessibility for other demographics 

(e.g. color blindness, dexterity impairments)? Or, is cloud-based accessibility solely 

relied on for the “tails” of the normal distribution bell curve (e.g., deaf-blind)? These are 

questions that need to be addressed to gain a better understanding of the potential benefits 

and implementation considerations of cloud-based accessibility in voting.

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. 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.
20

References

[1] C. Lewis. 2011. Issues in web presentation for cognitive accessibility. In 

Proceedings of the 6th international conference on Universal access in humancomputer interaction: design for all and eInclusion - Volume Part I (UAHCI'11), 

Constantine Stephanidis (Ed.), Vol. Part I. Springer-Verlag, Berlin, Heidelberg, 

244-248.

[2] Chisnell, D., Davies, D. and Summers, K. Any device, anywhere, any time: A 

responsive, accessible ballot design (2013). The Information Technology & 

Innovation Foundation (ITIF) Working Paper #007. 

http://elections.itif.org/reports/AVTI-007-Chisnell-Davies-Summers-2013.pdf

(Retrieved 2014).

[3] Cloud4all, http://www.cloud4all.info/.

[4] Cloud Services Measurement Initiative Consortium (2014). Service 

Measurement Index. http://csmic.org/ (Retrieved 2014).

[5] D. Mulfari, A. Celesti, A. Puliafito, and M. Villari. 2013. How cloud computing 

can support on-demand assistive services. In Proceedings of the 10th 

International Cross-Disciplinary Conference on Web Accessibility (W4A '13). 

ACM, New York, NY, USA, Article 27, 4 pages. 

http://doi.acm.org/10.1145/2461121.2461140.

[6] European Union 7th Framework Programme for Research and Technological 

Development. http://cordis.europa.eu/project/rcn/101353_en.html (Retrieved 

2014).

[7] Global Public Inclusive Infrastructure, http://gpii.net/. 

[8] Help America Vote Act of 2002 (HAVA), Pub. L. No. 107-252, 116 Stat. 1666-

1730 (2002), codified at 42 U.S.C. §§15301-15545. 

http://www.fec.gov/hava/law_ext.txt

[9] Identity, Credential, & Access Management. 

http://www.idmanagement.gov/identity-credential-access-management

(Retrieved 2014).

[10] ISO/IEC 24751-2:2008, Information technology – Individualized adaptability 

and accessibility in e-learning, education and training -- Part 2: "Access for all" 

personal needs and preferences for digital delivery.

[11] Mace, R., Hardie, G., Place, J., (1991). Accessible Environments: Toward 

Universal Design. In: Design Intervention: Toward a More Humane 

Architecture. Preiser, W.F.E., Vischer, J., & White, E.T. (Eds.) New York: Van 

Nostrand Reinhold.

[12] Martínez, J.A., Vanderheiden, G., Treviranus, J. GPII and CLOUD4All: AutoPersonalization for Universal Accessibility. European Commission, FP7 Project 
21

289016 (2012). http://cloud4all.info/pages/news/detail.aspx?id=6&tipo=2

(Retrieved 2014).

[13] Mell, P. M., Grance, T. (2011). NIST SP - 800-145 – The NIST Definition of 

Cloud Computing.

[14] Lee, S., Xiong, X., Yilin, L. E., and Sanford, J. (2012). EZ Ballot with 

Multimodal Inputs and Outputs. ACM Assets’12, Boulder, Colorado, October 

22-24, 2012. DOI 10.1145/2384916.2384960. http://elections.itif.org/wpcontent/uploads/EZ-Ballot_ASSETS-final.pdf (Retrieved 2014)

[15] NISTIR 7770, Security Considerations for Remote Electronic UOCAVA Voting 

(2011). http://www.nist.gov/itl/vote/upload/NISTIR-7700-feb2011.pdf 

(Retrieved 2014)

[16] NSTIC http://www.nist.gov/nstic/index.html

[17] Prime III http://www.primevotingsystem.org/

[18] U.S. CIO. Agencies Have Identified 78 Systems Migrating to the Cloud (2012). 

https://cio.gov/wpcontent/uploads/downloads/2012/09/IT_Reform_Agency_Cloud_Migrations_FI

NAL.pdf (Retrieved 2014).

[19] U. S. Department of State. Library Services. http://www.state.gov/m/a/ls/

(Retrieved 2014).

[20] The U.S. Election Assistance Commission http://www.eac.gov

[21] Vanderheiden, G., et. al. Creating A Global Public Inclusive Infrastructure 

(CLOUD4ALL & GPII), AEGIS International Conference, December 2011 

Brussels, Belgium. (Retrieved 2013 from

http://gpii.net/sites/default/files/2011%20AEGISCreating%20a%20Global%20Public%20Inclusive%20Infrastructure-Final.doc).

[22] Voluntary Voting System Guidelines (VVSG) 

http://www.eac.gov/testing_and_certification/voluntary_voting_system_guidelin

es.aspx (Retrieved 2014)

[23] Voter Persona Sketches. Information Technology and Innovation Foundation 

(ITIF) Accessible Election Design Workshops 2012. 

http://elections.itif.org/projects/design-workshops/voter-personas/ (Retrieved 

2013).

[24] Voter Personas. Accessible Voting Technology (AVT) Research Workshop 2013. 

http://www.nist.gov/itl/iad/upload/AVTR_Workshop_Voter_Personas.docx

(Retrieved 2013).
These personas are based on ethnographic observations and interviews by researchers at CATEA as part of the EAC-funded ITIF Accessible Voting Technology Initiative. 

elections.itif.org/projects/design-workshops/voter-personas/ Additional personas were added for the NIST Accessible Voting Technologies Workshop.

Appendix A – Categorized Voter Personas

Voter Personas: Designing for people who can vote independently

Tasha

Tasha is a woman who runs her own business. She has been blind 

since birth. She employs a “reader” who reads print materials to 

her. However, she uses a computer independently and prefers that 

method for accessing information.

Minjun

Minjun (pronounced Min-Joon) has vision loss, including being 

color blind. As a recent immigrant to the U.S., English is 

Minjun’s second language. Although he can remember who the 

candidates are from seeing them on TV, he has problems 

reading their names.

Amy

Amy is a single working mother who needs to pick up her 1 year 

old daughter at the daycare center before going to the poll to 

vote. The child is quite active and tends to wander off in public 

places. To make sure that her daughter does not wander off, Amy 

will have to hold her in her arms while she is voting.

Tyler

Tyler is a college student who has a condition that has resulted 

in blindness since he was a child, and more recently, mobility 

and fine motor issues that resemble arthritis. He can operate 

controls and buttons if they aren’t too small or too stiff. At 

home, he uses a computer with speech capability.

Michael

Michael is a retiree with a significant hearing loss. He uses hearing 

aids and can lip read if he is within a few feet of the speaker and the 

lighting is good.

Angela

Angela has quadriplegia from a spinal cord injury. She can 

move her arms somewhat, but is not able to grip items or point. 

She uses a typing stick, held on to her hand with a splint, when 

she wants to hit keys on a computer keyboard. Angela uses a 

power wheelchair and has a service dog. Due to the height of 

her chair, she frequently bumps her knees when she tries to pull 

up to work surfaces. She often feels rushed when voting.
These personas are based on ethnographic observations and interviews by researchers at CATEA as part of the EAC-funded ITIF Accessible Voting Technology Initiative. 

elections.itif.org/projects/design-workshops/voter-personas/ Additional personas were added for the NIST Accessible Voting Technologies Workshop.

Voter Personas: Designing to reach across the digital divide

Mary

Mary is 86 years old. She kept the books for her husband’s small 

farm until he passed away. Now she mostly watches TV if she can 

sit close so she can see and hear it. Hearing aids might help her, but 

she thinks she can’t afford them. Her granddaughter got audio 

books for her but Mary can’t always remember how to use the tape 

machine to play them. She wonders how she will vote now that it’s 

difficult for her to read print and to hear people talking. She does 

not want an absentee because she worries it might get lost in the 

mail.

George

George is a retiree who has MS that affects his memory and 

his mobility. He uses a cane and can’t stand for long 

periods at a time. Because of his memory problems, he 

needs to bring notes with him to the polling station about 

how he is going to vote. He is very concerned about voting 

privacy — he misses the privacy of the old designs with the 

curtain.

Minjun

Minjun (pronounced Min-Joon) has vision loss, including being 

color blind. As a recent immigrant to the U.S., English is Minjun’s 

second language. Although he can remember who the candidates 

are from seeing them on TV, he has problems reading their names.

Charlie

Charlie has autism. He is high-functioning and is able to 

read well. However, he is uncomfortable in crowds and in 

unfamiliar situations, and he is sensitive to loud noises. He 

also tends to persevere when doing some tasks, and it is 

difficult to get him to move on to the next activity.

Tonie

Tonie lives in an inner-city neighborhood. She dropped out of high 

school, after her poor reading skills made classes too frustrating. 

She wants to have a voice in her community, but almost missed the 

last election because she did not know where to go vote, and did not 

know how to find the information she needed. 

Kevin

Kevin is in a VA rehab hospital, recovering from injuries 

from an explosion in Iraq. He is still learning to use 

prosthetic arms, work made more difficult by difficulty 

concentrating and sensitivity to bright light. He needs help 

remembering to request an absentee ballot, and how to fill it 

in and return it on time. 
These personas are based on ethnographic observations and interviews by researchers at CATEA as part of the EAC-funded ITIF Accessible Voting Technology Initiative. 

elections.itif.org/projects/design-workshops/voter-personas/ Additional personas were added for the NIST Accessible Voting Technologies Workshop.

Voter Personas: People who need assistance or are in assisted living facility

Mary

Mary is 86 years old. She kept the books for her husband’s small farm 

until he passed away. Now she mostly watches TV if she can sit close 

so she can see and hear it. Hearing aids might help her, but she thinks 

she can’t afford them. Her granddaughter got audio books for her but 

Mary can’t always remember how to use the tape machine to play 

them. She wonders how she will vote now that it’s difficult for her to 

read print and to hear people talking. She does not want an absentee 

because she worries it might get lost in the mail.

Angela

Angela has quadriplegia from a spinal cord injury. She can 

move her arms somewhat, but is not able to grip items or 

point. She uses a typing stick, held on to her hand with a splint, 

when she wants to hit keys on a computer keyboard. Angela 

uses a power wheelchair and has a service dog. Due to the 

height of her chair, she frequently bumps her knees when she 

tries to pull up to work surfaces. She often feels rushed when 

voting.

Charlie

Charlie has autism. He is high-functioning and is able to read 

well. However, he is uncomfortable in crowds and in unfamiliar 

situations, and he is sensitive to loud noises. He also tends to 

persevere when doing some tasks, and it is difficult to get him to move 

on to the next activity.

Maria

Maria is a retiree who has cerebral palsy that affects her 

mobility and her dexterity. She uses a scooter and has limited 

fine motor control. As a result, she has difficulty reaching and 

grasping objects as well as using interfaces that have small 

buttons or controls.

Tyler

Tyler is a college student who has a condition that has resulted in 

blindness since he was a child, and more recently, mobility and fine 

motor issues that resemble arthritis. He can operate controls and 

buttons if they aren’t too small or too stiff. At home, he uses a 

computer with speech capability.

Kevin

Kevin is in a VA rehab hospital, recovering from injuries from 

an explosion in Iraq. He is still learning to use prosthetic arms, 

work made more difficult by difficulty concentrating and 

sensitivity to bright light. He needs help remembering to request 

an absentee ballot, and how to fill it in and return it on time.
Appendix B – Components of the Global Public Inclusive Infrastructure [21]

Components marked with a thick black frame are being developed under the Cloud4All project.
Appendix C – NGVP Technical Diagram

*XML22: Extensible Markup Language

*JSON22: JavaScript Object Notation

 

22 Disclaimer: Any mention of commercial products or reference to commercial organizations is for information only; it does not imply recommendation or 

endorsement by the National Institute of Standards and Technology nor does it imply that the products mentioned are necessarily the best available for the 

purpose