Partner Introduction

Our partners in the accessibility industry who helped us develop our user-friendly widget.

Wheelchair Alliance

The Wheelchair Alliance works to provide critical resources that empower individuals who use wheelchairs, along with their families and caregivers. Their wheelchair services data and practical insights have significantly shaped the development of our accessibility widget.

GDI Hub

The UCL academic research center specializing in disability innovation and accessible technology. GDI Hub has provided valuable insights into inclusive design principles and helped us organize invaluable testing sessions with members of the visually impaired community.

Soundscape Community

A leading innovator in accessibility solutions for visually impaired individuals. Soundscape's expertise helped us design features that enhance the widget's voice interface and make the design visually-impaired friendly.

Esri

A global leader in geographic information system (GIS) software and location intelligence. Esri's insights helped us develop scalable and easy-to-use mapping technology.

We are also very thankful to have been able to work with Team 15's SightLinks and to have been able to use their product.

Project Background and Goals

The Challenge

The lack of reliable, up-to-date accessibility information in urban environments is a challenge millions face with every day. While mainstream navigation providers such as Google Maps provide substantial data sets on data layers such as restaurants or car parks, individuals with mobility challenges struggle to navigate cities due to missing or inaccurate data about zebra crossings, wheelchair ramps, and obstacle-free pathways.

By leveraging Team 15's expertise in machine learning and satellite imagery analysis, as well as using a Wheelchair-alliance wheelchair services data set, we are tackling this problem directly. Integrating these insights into our widget ensures that users receive real-time, precise data, reducing uncertainty and frustration when planning routes.

Our Approach

Our project aims to create a comprehensive database for accessibility, filled with charity-backed data sets, empowering users to navigate urban environments with confidence and ease. We will develop an intuitive widget that developers can seamlessly integrate into their websites, supported by detailed documentation.

This widget will incorporate advanced location services and data visualization tools to enhance usability, as well as have a variety of accessibility focused features to suit everybody's needs.

Technical Goals

Solving Existing Problems

  • Address Fragmented Data: Aggregate and standardize accessibility data into a single, reliable database with charity (or other trusted entities's) provided data layers.
  • Overcome Integration Challenges: Provide a lightweight, easy-to-integrate widget with clear, developer-friendly documentation.
  • Enhance Data Accuracy: Use crowdsourcing to provide consistent community-backed updates to ensure users always have the most accurate information.
  • Ensure Cross-Platform Compatibility: Integrate with existing commonly-used mapping and navigation systems.

Non-Technical Goals

The Bigger Picture

  • Empower Independence: Enable individuals with disabilities to navigate urban environments confidently.
  • Build a Community-Driven Platform: Build an easy space for users to enrich the data.
  • Advocate for Inclusivity: Promote accessibility as a fundamental right.
  • Inspire Systemic Change: Demonstrate the value of how just simple additions of accessible features in mapping technology improve user experience to inspire adoption.

Requirement Gathering

Requirement Collection Methods

We conducted semi-structured interviews on users of our product - software engineers and visually impaired people to gather insights into their needs. Software engineers discussed technical challenges and API requirements, while visually impaired individuals focused on accessibility needs, especially the ones connected with colours and different themes. Regular consultations with our partners helped judge and integrate their feedback effectively.

User Interviews: Themes, Challenges & Insights

We faced several challenges during our interviews. We especially had difficulties in judging which accessibility features to implement first (some visually impaired users found the Focus Mode functionality useless, while others found it incredibly useful). We also realized that a voice interface should be added to the requirements, even though it wasn't one of our core requirements in the beginning.

Interview 1: Visually Impaired Person

What are some common challenges that you face when navigating public spaces?

One of the biggest challenges is the lack of information about my surroundings. It's difficult and scary to navigate an area that you are not familiar with.

Do you use any GPS apps and if so, do they address your challenges appropriately?

I use common applications like Google and Apple Maps, but they don't provide enough information about things like locations of staircases, entrances, barriers, etc. There isn't enough for people with special accessibility needs.

Would you find it helpful to have certain tags and markers on a map indicating these types of objects?

Yes, that would be very helpful.

What would be your preferred way of interacting with this app?

A mobile interface would be most convenient and portable for me. In addition, I would prefer if there was an audio description feature accompanying a UI with accessibility features (e.g., large text, contrast in colours, etc.).

Interview 2: Software Engineer

What challenges do you face with location-based applications?

Handling varying data sources and making sure it is accurate, structured data for different use cases is a major challenge. Especially when dealing with different resolutions or temporary obstacles.

How do you typically manage geospatial data?

I use APIs like Google Maps and OpenStreetMap, along with tools like what3words for precision. The challenge is integrating and presenting this data, especially with varying resolutions.

What features would be helpful in an API for your projects?

An API should support multiple data layers, allow querying by location, handle grid-based data with adjustable resolutions, and support metadata like reliability or expiry dates.

How should data be displayed in a frontend widget?

A map interface with clear markers, voice input, and location-based search would be ideal. Users should easily toggle between layers.

Would you find features like temporary object flags or voice search useful?

Yes, these features would enhance usability and ensure accurate, dynamic data, especially in real-time environments.

Personas

Here we present our potential users of our technology.

Persona 1 - Eva Liebert

Eva Liebert

"I like to explore the nature in my city."

Eva is a retired geologist who enjoys exploring parks and accessible trails. She values tools that help her navigate with ease and locate wheelchair-friendly facilities.

Persona 2 - Mike Watson

Mike Watson

"I want to use a tool that warns me of obstacles in my path."

Mike is a visually impaired DJ who loves exploring urban landscapes with his guide dog. He seeks tools that provide real-time obstacle warnings and accessible navigation.

Use Cases

Here we present a diagram which depict how the users will interact with our final product as well as describe use cases in more detail separately.

Use Case Diagram

Use Case: Viewing and Navigating to Nearby Facilities

ID UC1
User User
Description Viewing nearby facilities / hazards
Flow
  1. Open the website
  2. Click on accessible widget map
  3. Accept location permission prompt, centering map on location of user
  4. Click on the datalayer toggle button to filter for selected objects in the 10 mile radius.
  5. Pan o move around the map / Use the shortcuts under the map to navigate to the three closest data points and then click on the data point markers to investigate them further. Information about hazards, additional accessibility information and spatial info will appear.
  6. Click on the directions button to get GoogleMaps directions to that specific location.
Result The user is able to see and navigate to nearby accessibility facilities.

Use Case: Navigating to a Particular Destination

ID UC2
User User
Description Navigating to a particular destination
Flow
  1. Open the website
  2. Click on accessible widget map
  3. Accept location permission prompt, centering map on location of user
  4. Use search bar, entering what3words or address, or a postcode
Result The user's map is centered at a particular destination, with loaded accessibility information displayed on the widget.

Use Case: Adjusting Visual Features

ID UC3
User User
Description Adjusting visual features
Flow
  1. Open the website
  2. Click on accessible widget map
  3. Accept location permission prompt, centering map on location of user
  4. Toggle wanted accessibility features, such as dark theme, focus mode and dyslexia-friendly font.
Result The user is able to personalize their experience.

Use Case: Reporting Accessibility Features

ID UC4
User User
Description Report accessibility feature
Flow
  1. Open the website
  2. Click on accessible widget map
  3. Accept location permission prompt, centering map on location of user
  4. Toggle the selected data layer on
  5. Click on any data point from that specific data layer
  6. Click on Report Features button and select all accessibility features / warnings to report
  7. Click Submit
  8. Sends POST request via API to update our data base
Result The accessibility feature is reported successfully

Use Case: Use the voice interface

ID UC5
User User
Description Use the voice interface for hands-free navigation
Flow
  1. Open the website
  2. Click on accessible widget map
  3. Accept location permission prompt, centering map on location of user
  4. Press the microphone button under the map
  5. Say the data layer you want information for
  6. Voice interface tells you the location and accessibility features of the nearest location and asks you whether you want navigation there
  7. Confirm / Cancel the navigation
Result Navigation to selected data layer completely hands-free

Use Case: Embedding the Widget in a Website

ID UC6
User Developer
Description Embedding widget in a website
Flow
  1. Details are provided in Appendices, under the Implementation manual section
Result The widget is successfully set up on the website

MoSCoW Requirement List

Prioritized requirements using the MoSCoW method (Must have, Should have, Could have, Won't have).

Functional Requirements

Must Have

  1. Database with accessibilty-focused data layers (at least wheelchair services and zebra crossings), with support for multiple resolutions (0.5mx0.5m, 3mx3m).
  2. API functionality to receive coordinates, object type and reliability flags of datapoints and load them into the database.
  3. A widget where selected datalayer geolocation points are represented on a Google-maps like background with markers. The widget must be easily integratable into websites.
  4. Add what3words grid overlay and colour the cells the datapoint cover to depict spatial information.
  5. Functionality that locates the user and locates the closest points, ordered by Mahattan distance.
  6. Dark and yellow mode to improve accessibility.

Should Have

  1. A visual webpage representation of the database where data can be downloaded and uploaded in a JSON format.
  2. Data points in widget should have icons for better user experience.
  3. Widget should have dynamic options that the developer can specify.
  4. Link to navigate to any datapoint via Google Maps.
  5. Widget should have text-to-speech and speech-to-text functionality for hands-free navigation.

Could Have

  1. Users of widget can report additional accessiiblity features of data points through a form.
  2. Database website has an intuitive UI with icons and drag-and-drop functionality.
  3. Datalayers such as traffic lights and an obstacle layer (tables in front of cafes, bollards) are added.

Won't Have

  1. We will not develop our own navigation technology.

Non-Functional Requirements

Must Have

  1. Efficient handling of data retrieval and storage for fast real time API requests.
  2. Clear documentation for API and widget integration.

Should Have

  1. Clear documentation for uploading / downloading data on the database website.

Could Have

  1. Telemetry data for API monitoring performance and usage.
  2. Scalable system for easy addition of more data layers.
  3. Mobile support for the widget.

Won't Have

  1. The database will not allow any other format than the specified one to be received (like photos).
  2. We will not have verification / log-in functionality.