Introduction

Limited access to public building is a fact of life for persons with disabilities. While the Americans with Disabilities Act of 1990 (Access Board, 2005) has greatly improved access, people with disabilities continue to be challenged in the community by buildings with architectural barriers. Currently very little information is available to inform people about accessibility information in advance of a visit. Thus, people must visit a building in advance to scope out access. The high burden of participating in the community is often too high, causing many persons with disabilities to opt out of community events.

Seeing this need, we sought to develop an intervention that would increase the community participation of individuals with disabilities by creating a system to inform persons with disabilities about the accessibility of public buildings. Given the large scope and need to share mass amounts of information, we decided an application would be the best modality for our intervention.

While several attempts have been made to create web databases on accessible buildings, they are scantily used and tend to focus on specific types of buildings. They also provide only summary data that do not detail accessibility issues or allow for custom searches (DisabilityGuide.org, n.d.; Wired on Wheels, 2001).

MethoDs

Once we understood our goals we began upon the development of our application based intervention. Development occurred in four steps, conceptualization, design, and implementation, and testing/revision. This section will describe the process.

Conceptualization

The first step in the development process is to develop and refine a concept. While we knew that we wanted to create a system of accessibility information available to consumers, it was necessary to draft out the specific details and capabilities of the system. After several conceptual iterations we developed the Access Ratings for Buildings (AR-B) system (R2D2 Center, n.d.). The AR-B system will have mobile and web-based capabilities for providing up-to-date personalized accessibility information about public buildings for people with disabilities, their families and friends, and others. The AR-B system has two components. One component allows a trained evaluator to investigate a building for accessibility. The second component allows consumers to rate and share experiences and obtain accessibility information to meet their needs. These highly integrated systems will be able to share information. Armed with relevant accessibility information, consumers can determine which establishment will best serve their needs, plan alternatives, bring assistance, or even avoid particular barriers. Furthermore, information can be shared to business owners who may then choose the increase the accessibility of their facility to improve the experience for patrons with disabilities and even their general customers.

Once the idea has a set purpose and goal, it is necessary to identify the target users and their motivations. Very early, we identified three groups of users for our system: 1) the general public, including people with disabilities, 2) trained raters, 3) building owners, administrators, and policymakers. Each of these groups has different motivations and requires different functionality in the system. This paper focuses on the “consumer” app component of the system used by a member of the general public to retrieve and submit building accessibility information.

For our general public user, we foresee three primary motivations: 1) making an informed choice between locations, 2) looking up a specific location in order to plan around barriers, 3) providing feedback on building accessibility. While thinking about our users, we discovered several other important characteristics. Many users would like to find information while they are out in the community (i.e. an app on their smartphone), but many other users may not have a smartphone or otherwise prefer to access information on their computer at home or public kiosks. Also, since users tend to remember the accessibility of buildings they have visited, they will generally be preparing to visit a building for the first time when looking for accessibility information. Finally, in order to maximize the number of users who interact with the system, the time required for common interactions must be minimized.

From the user motivations we extracted two intertwined questions: 1) what information do users want/need to make informed decisions/plans? 2) what information do users want to tell others?

After identifying users, it was also necessary to identify team members needed to complete these capabilities. In the end, our team was composed of….

• Rehabilitation professionals for developing content
• Research expert to facilitate methodology around complete a valid and reliable system
• Designer for visual and user interface design
• Several programmers to implement the system in a variety of platforms
• Individuals with disabilities to ensure optimal usability
• Lawyer to assist with drafting of legal documents (e.g. terms of service)
• Marketing team to assist in bringing product to market
• Moderators to review content posted by users

At the end of this stage, we were able to verbalize the innovation we wanted to create as well as how we planned on completing the project and who we would need to complete it.

Design

In the design phase we chose how to present questions and how to create the system.

First, we had to choose a platform for development. For some projects, it is possible to use responsive web design to develop a single website for use on both smartphones and traditional computers (Marcotte, 2010). However, we opted for Android and iOS native apps with a website for traditional computers.

In order to reduce development time and effort, both the native apps and website are designed to use the same server-based Application Programming Interface (API). The API server handles storing and retrieving information from a database, and implements most of the “business logic” (e.g. finding and ranking results of searches). Nearly all of the app’s content is populated using the API, as this allows content updates without updating the app itself.

Deciding how to portray the information was challenging due to the diverse options. For example, a multiple choice question can be displayed using check boxes, radio buttons, a drop down list, or a slider. The user could have the opportunity to choose one or many responses. Additionally, there are extensive style options in terms of coloring, font, and item placement on the screen. Of course accessibility of the information to the users was paramount.

We used interface mockups to facilitate conceptual design discussions and drive out details (see Figure 1). The mockups depicted smartphone interfaces, as the size and interaction methods place more constraints on the design. These mockups were mostly static images, but had clickable regions to allow movement between screens.

A variety of flow charts were also used in the design phase (see Figure 2). These ranged from showing the relationships between concepts, to how users move between screens/functions, to details of the data representation in the database.

A key point of the design phase is that the scope of project should be minimized. Jumping straight to the full potential scope of the project greatly increases the complexity (and therefore time required) of both design and implementation. Many potential features were pruned from our design, but we have kept a list of them which will be revisited after user testing to determine future direction.

At the end of this stage we had initial documentation of the proposed system, the capabilities and how we would prefer them to be implemented. This led us to the next step of implementation.

Implement

We found documentation to be essential for communicating within and between the teams working on the project. The detailed technical documentation for the API helped insure the API and apps could understand each other. The mobile app mockups used in the design phase were expanded, and annotations were added to describe dynamic behavior not visible in the static mockups. These annotations included where and how the various API calls are used. Thus, the API documentation and mockups provided a full specification to the mobile app development team.

However, when creating mockups, some details are inevitably left out. While similar, Android and iOS use different conventions. For example, Android apps usually use the physical “back” button to go back to the previous screen, whereas iOS devices have no physical button, so the “back” button must appear on the screen. Additionally, if the screen layout changes between landscape and portrait orientations, the number of mockups necessary to depict all possibilities doubles. We decided to only produce mockups for portrait orientation, and instructed the app developers to use a “zoomed/stretched” version of the same layout for landscape. A major benefit of creating documentation is that it forces the creator to think deeply about the topic which often highlights issues with the current plan.

The native mobile apps are implemented using a free cross-platform development framework, Appcelerator Titanium (Appcelerator, n.d.). This allows the Android and iOS apps to use mostly the same code, reducing development time. Since people with disabilities are the primary audience for this app, particular emphasis has been placed on the accessibility of the app, including support for screen readers, sufficient contrast, font size, and control size.

Terms of service and privacy policy documents are easy to overlook when starting to build an app, but they are important for protecting the organization and users. Our University’s lawyers did not have experience drafting these types of documents, so we examined and synthesized points from similar services to create the first draft of the documents.

Another unexpected hurdle was joining the Apple iOS Developer Program. Joining is required since apps must be digitally signed before they can be deployed to iOS devices, even for testing purposes. Apple requires documentation that the organization is what they claim, and the contract must be signed by someone with proper authority. We leveraged the team from our institution's IT services, who had already joined the Apple and Google developer programs.

At the end of this stage we had a functioning application. But as with any process, testing and revisions were needed.

Testing and Revision

We are currently in the testing process. Several levels of testing are required. First, it is essential to ensure the application is functioning as intended and that there are no broken buttons or page links. Second, after the application is considered to be functional, it is necessary to ensure that a typical consumer would be able to use the application quickly and efficiently. Outside users help us to validate the conceptual design of the system, and improve usability of the interface. As one of our main audiences is consumers with disabilities, much of our user testing is focused on accessibility of the application for users of all abilities. Once our application passes these levels of testing and revisions are made, we will enter the beta testing process, where a limited number of applications are released for public use.

Discussion

Creation of the AR-B consumer application has been a lengthy process consisting of conceptualization, design, implementation, testing and revision. At the end of this process, we have a functioning application that helps persons with disabilities and their family and friends share and learn about the accessibility of their community. Hopefully, as our system becomes more widely available, our application based intervention will help consumers with disabilities more widely participate in their community.

This process also significantly increased our knowledge of 21st century rehabilitation engineering. While the transition to the application has allowed our intervention to all encompassing and easily accessible, our experience in creating an app was full of unexpected hurdles. One must be careful not to get stuck in the details. Our project was delayed nearly a year by extended theoretical discussions. In sharing our experiences with other innovators, we hope that we can improve the knowledge base of rehabilitation engineers to increase the prevalence of rehab type apps available.

Our progress thus far is a significant development. Further research, however, is needed to better develop system capabilities, complete psychometric testing, and to implement the system into current practices so that benefits can be realized by consumers.