Accessibility - benjaminsunliu/ConUMap GitHub Wiki

FEATURES

To make our application accessible to all users, here are some issues/features to consider:

1. Restricted mobility

  • Step-free routing: Prioritize elevators, ramps, and curb cuts.
  • Terrain data: Informs users of surfaces like gravel or steep slopes.
  • Real-time updates: Alerts users to broken elevators or construction.

2. Motor/ Physical Impairments

  • Large touch targets: All interactive elements must be a fairly large, minimum pixel size (eg. 44x44 pixels on iOs & 48x48 on Android, per guidelines). This gives physically-impaired users (and non-impaired users alike) more leeway when clicking a button, so they don’t have to be very precise per tap.

  • Gesture alternatives: Focus on simple taps instead of swipes or pinches. Avoid features that require shaking, tilting, or rotating the device, as these are often impossible for users with limited mobility or those using mounted devices. (Eg. to delete something, there should be a delete button - the user shouldn’t have to swipe the element-to-delete.)

  • Switch Access support: Switch Access is “an accessibility feature that allows people with severe motor impairments to use a smartphone, tablet, or computer without touching the screen.” There are several things to consider, as a dev, regarding Switch control: Focus Order: Switches move in the order you’ve laid out your code. If the "submit" button is technically the first thing in your code but appears at the bottom of the screen, the highlight will jump around randomly, which can confuse the user. Grouping: If you have several small buttons in a grid, a switch user has to click many times to get past them. Instead, by "grouping" them in a container, they can skip the whole block with one click. Invisible Elements: If a button doesn't have a text label (eg. a "plus" icon with no description), the Switch Access software won't know it's a button and might skip it entirely.

  • Voice Control support: Provide clear content descriptions so Voice Control users can trigger actions by name.

  • Flexible Timing: Allow users to extend or disable time limits for interactions/prompts, as motor impairments can increase the time needed to react to those.

*Note: For experimentation, you can install the following browser to simulate various disabilities or difficult conditions people may have: Web Disability Simulator - Chrome Web Store

3. Illiteracy / Visual impairments

Some key takeaways regarding developing & writing for users with lower levels of literacy are that they rely on visual cues, linear paths, and the information & intuition provided by icons rather than dense text.

  • Color-coded, simple routing: Use consistent colors (e.g., "follow the green line for the shuttle") to guide navigation.

  • Emphasize icons in UI: Ensure to use universal icons and photos instead of text. The icons should be consistent across building type, department, etc. Moreover, ensure to supplement with photos of buildings instead of just text names.

  • Voice Control support: Much like for those with physical impairments, it is crucial to provide clear content descriptions so Voice Control users can trigger actions by name. Moreover, users should be able to speak the destinations and listen to verbal/spoken turn-by-turn guidance. In short, ensure voice-guided navigation and screen-reading support.

4. Epilepsy

According to the World Health Organization, around 50 million people worldwide have epilepsy, making it one of the most common neurological diseases globally.

  • Strobe-free design: Do not include any content flashing between 3Hz and 30Hz.
  • Reduced motion: Disable non-essential sliding / zooming animations.
  • Static media: Replace auto playing videos or GIFs with "tap to play video”.

5. Neurodivergence

  • Predictable layout: Ensure consistent UI patterns. This makes the app easier on the mind & overall easier to use, as well.
  • Quiet routes: Include the option, when requesting directions from/to a class and/or a building, to suggest paths that avoid high-traffic or noisy areas.
  • Literal instructions: Use direct, unambiguous language and simple sentences in the instructions (e.g., "Go to the red door").

Additional Documentation for Accessibility & APIs

React Native Accessibility Guide: Documentation on accessibilityLabel, accessibilityHint, and accessible props.

WCAG Mobile Accessibility Standards: The global gold standard for mobile accessibility.

Google Maps Platform Documentation: Essential for managing API keys and fetching directions between the two campuses.