Keywords

1 Assessing the Need and Requirements

1.1 What We Don’t Know

Providing a diverse and inclusive experience for all members of the UVA community and guests has been a long-standing goal at the highest levels of the University. Because of the historic nature of our built environment, the topography of our setting, and the increased dependence on the digital world, assuring inclusion for individuals with disabilities has been challenging. A number of committees and individuals have worked diligently over the years to identify and address these barriers. However, a lack of resources combined with the lack of a reporting process or mechanism have resulted in many barriers remaining unknown or unreported.

Due to the lack of formal reporting mechanisms those issues brought to the attention of these committees or individuals were not properly tracked to assure an issue was addressed.

In addition to the lack of tracking, oftentimes the wrong individual was initially notified. It sometimes took many attempts to locate the appropriate office or individual equipped to address the situation. Because of the amount of extra time and effort involved, it was not uncommon for issues to become buried in the mounting list of daily tasks, resulting in an issue being addressed after a lengthy time or not at all.

2 Recent Consent Decrees and Resolution Agreements

As we saw peer institutions enter into consent decrees and resolution agreements with regulatory agencies, UVA understood it was in our best interest to review these documents, assess the requirements presented, and determine the direction we should take.

Within the past five years, the necessity for some type of reporting or survey mechanism was either indirectly or directly stated in the documents reviewed and referenced [4,5,6,7] as well as in other agreements. In short, the tool required by the regulatory agencies needed to assist the institution in identifying barriers to access, provide tracking on the remediation of these discoveries, and offer sufficient information to deliver requisite reports.

Based on this review the decision was made to move forward with the creation of a pan-university online reporting system, addressing barriers in both the digital and built environments. Since UVA was not under review by any regulatory agency at the time, this would be a proactive approach to identifying barriers and incorporate similar to the approaches envisioned in the documents reviewed.

3 Proactive Holistic Approach

3.1 Review of Peer Institution Reporting Methods

Our first step involved a review of how our peers were addressing this challenge. Many of the websites of institutions highlighted in the EDUCAUSE document [7] were reviewed. Those institutions that did have a reporting tool in place most commonly offered a basic web-based form, linked from their disability services office page or ADA Coordinator office, with the information provided going back to a single person. These forms also tended to address only the digital environment or only the built environment. In some situations, there were two separate forms - one for each environment and each located through different web paths.

Some of the forms that focused on the built environment provided a complete list of campus facilities to choose from. In one instance the list included over 75 facilities. The person reporting the issue would then choose the location with the barrier from a dropdown list.

Those forms that were specific to the digital environment often automatically filled in the web address of the web page that was being reviewed at the time the form was activated.

Although these processes and methods of obtaining information regarding accessibility barriers would result in the identification of certain issues, auto-completion of information sometimes created more of a problem by indicating the wrong source of the issue. For instance, if we offered a dropdown list of facilities, the number of facilities needing to be listed would make the selection process untenable. If we auto-filled the location of a webpage, the issue may have actually been found in another location and the reporting page would be incorrect.

3.2 Drivers and Intention

Identification, prioritization and remediation of accessibility barriers coupled with centralization and coordination of effort were the primary drivers in moving forward the creation of the reporting tool for UVA.

It was clear that models our peers installed in their environments would not work at UVA. One of our first priorities was to identify key stakeholders who are commonly associated with accessibility issues within the University environment and enlist the support and participation of these offices and individuals.

Before moving forward, a meeting was held with University Counsel’s Office, to ensure the direction and process of this initiative met with their approval, ask for suggestions and answer any questions they may have.

3.3 Identification of Key Stakeholders

To begin the process of enlisting support and participation, we met with key individuals in areas common to accessibility barriers. In addition, meetings were held with areas that provide support to persons with disabilities at UVA. These areas included:

  • Parking and Transportation

  • Facilities Management

  • Information Technology Services

  • Student Disability Access Center

  • Office of the Executive Vice President and Provost

  • Department of Athletics

  • Intramurals and Recreational Sports

  • Equal Opportunity and Civil Rights Office.

These offices were cautiously enthusiastic about the idea of a reporting structure, not knowing what the additional workload may entail. Even with the unknown factors, each agreed to participate and appointed at least two members of their staff to participate in the effort, with one of these individuals being appointed the primary contact for their office.

3.4 Distributed Responsibility Model

Outside of the Student Disability Access Center, the number of individuals whose position is fully dedicated to accessibility in some way at UVA – regardless of environment – totals two; the ADA Coordinator, who reports through the Equal Opportunity and Civil Rights Office, and the Coordinator of Academic Accessibility, who reports through the Office of the Executive Vice President and Provost. Neither of these positions have time in their workday to address issues presented through the reporting mechanism. Instead of directing all reports to one person as our peers have done, it was decided to develop a distributed responsibility model to address the issues presented.

Eight teams were created from the stakeholders group. These teams were comprised of individuals across departments and units who could best address an issue based on the barrier type selected. For instance, the team responsible for addressing classroom or instructional barriers is comprised of individuals from Facilities Management, the Office of the Provost, Information Technology Services, and the Student Disability Access Center. This team then assigns tasks to members of their units to assist in addressing the situation presented (Fig. 1).

Fig. 1.
figure 1

The distributed model of addressing reports through the Report A Barrier tool

Full size image

Even with the distributed model, one department must “own” the tool as well as the process. The Equal Opportunity and Civil Rights office provides this oversight with the ADA Coordinator serving as the administrator of the tool.

4 Implementation of the Idea

4.1 In-House Development

Review of the process by the key stakeholders and Report A Barrier (RAB) Review Teams helped define necessary steps and workflow. Development of the tool was done by the Custom Application & Consulting Services group within UVA’s Information Technology Services unit using Drupal. It was important the tool’s format be responsive so input could easily be accomplished with a hand-held device such as a smartphone or tablet as well as a desktop or laptop computer. Functionality was also built-in allowing for the submission of a photo when an issue is reported.

It was also important the tool be easy to find and remember. Working with Information Technology Service and UVA Communications, the URL reportabarrier.virginia.edu was obtained as well as the reportabarrier@virginia.edu email address. Simple in form and easy to remember.

4.2 Basic Structure

Processes inherent to the tool all key off of the barrier type selected by the person reporting the issue. These types of barriers are not specific to a department or unit, but as was mentioned earlier, are more of an “area of concern” from the perspective of the person making the report. The barrier types currently in use are:

  • Parking & Transportation

  • Physical Environment/Facilities

  • Classroom/Instruction

  • Online Environment

  • Technology Related

  • Event/Program Access

  • Athletics/IMRec Facilities & Events

  • Other.

Each of these barrier types has a cross-department/unit team assigned to respond, determine if the correct barrier type has been selected, and address as appropriate.

In addition to the barrier types, a series of statuses has been developed to properly track the current state as an issue is being addressed. Each status may have a time trigger attached. As an example, the “New” status must be address by the corresponding RAB Review Team within three business days. If that target is not met, a reminder email is sent to the group (Table 1).

Table 1. Explanation of RAB statuses
Full size table

4.3 Process

In addition to the creation of the RAB Review Teams and the series of statuses, a number of email notifications are automatically generated and other processes behind the scenes are started when an issue is first submitted. There are four components to Report A Barrier:

  • Front-facing submission form

  • Back-end routing and tracking processes

  • Follow-up and response

  • Audit and records management.

Front-Facing Submission Form.

In an attempt to again keep things simple, the front-facing form has only three required fields with the remaining being optional, allowing for anonymous submission. A person must indicate their affiliation with the University (Student, Fac/Staff, or Guest), select a Type of Barrier, and enter a description of the issue in their own words. Other fields available for input are:

  • Location

  • Photo

  • Name

  • Email Address

  • UVA Computing ID (for those with UVA affiliation)

  • Phone Number.

Back-End Routing and Tracking Processes.

When a report is submitted, a series of email notifications are sent to the person submitting the case, the RAB Review Team assigned to the barrier type, and to the oversight team. Time triggers based on status are also started.

Follow-Up and Response.

All members of the RAB Review Teams have the ability to see and update any case submitted. These updates include notes that will be sent to the person submitting the report, internal notes that will be visible only to team members, and status updates. Authentication is needed to access these update screens and that access is controlled by the RAB administrator. If the person submitting the issue includes their email address, they will be notified of any updates (except for internal only updates) and status changes.

Audit and Records Management.

On an annual basis, or as request by senior leadership, a review of all cases not assigned a “Closed” status is performed and appropriate action taken to move them towards closure. An annual report is created providing a narrative of the number of issues identified and the response and remediation efforts undertaken. “Closed” cases are moved out of the active database, to an archive. Archived records can still be reviewed and updated when necessary but are out of the active group of cases. According to the Virginia Public Records Act [8], “Closed” cases must be destroyed three years after last action. This is done on an annual basis following UVA records retention policies.

5 Results and Lessons Learned

5.1 Results

A soft rollout occurred January through mid-April 2016. During that time, 13 viable cases were submitted. On April 18, 2016 communications were sent to the whole of the university under the signatures of the Executive VP and COO, Executive VP and Provost, and Vice President for Student Affairs. That day alone, 68 viable reports were submitted. Looking at January through December 2016, 148 viable cases were submitted. During 2017, 46 cases and January–March 1, 2018 only 11 cases have been submitted.

These numbers tend to indicate there was a pent-up demand for a vehicle to report such issues. Over half of the issues reported are in the built environment with just under half being reported by faculty or staff members.

The decrease in submissions can be attributed somewhat to a more proactive approach being consciously implemented when projects begin – in both the built and digital environments. More likely is the need for a renewed communications plan to alert the University community of the tool’s existence and how to use it.

5.2 Lessons Learned

By implementing the distributed responsibility model, greater awareness of accessibility issues in both the built and digital environments has been produced. It is not unusual to now hear our concrete sub-contractors discussing the need for curb cuts and the best way to install them. Or, listen to our digital environment developers discussing the need for captioning or alternative text during the production of a new tool. This awareness was not a planned outcome but it is certainly a welcome benefit.

Going forward, it is in our best interest to alert the University community to the availability of this tool, and other accessibility tools, at the beginning of each semester.

It is also important to keep the RAB Review Team engaged as the tool matures and processes need review. As the submission numbers have decreased over time, the hands-on involvement by team members has also decreased. It is important to keep everyone involved, learning from each other throughout the process, and build on the progress towards a more inclusive University this tool is helping us to create.