Overview
Proxi is committed to making the interactive map experience accessible to visitors of all abilities. This statement covers the public-facing map page that visitors interact with when they explore your district, event, or destination.
Our target standard is WCAG 2.1 Level AA — the benchmark referenced in the Americans with Disabilities Act (ADA) web accessibility guidance and most state and local accessibility requirement.
This statement describes what we have built, where shared responsibility exists between Proxi and your organization, and where we are continuing to improve.
What the Map Experience Includes
The visitor-facing map experience consists of:
Interactive map canvas — Google Maps with location pins and markers, pan, and zoom
Browse Locations panel — a full, searchable text list of every location on the map
Category and tag filters — chips for narrowing the location list by type, tag, check-in history, or saved status
Location detail cards — name, address, description, images, hours, special offers, and category tags for each location
Email capture modals — optional popups for collecting visitor contact information
Language selector — for maps with translation enabled
Header navigation — including the Browse Locations toggle, search, share, print, and bookmark controls
Challenge and scavenger hunt overlays — clue cards that protect hidden location information until participants check in
How the Map Is Accessible
The Text List Is the Primary Accessible Path
The interactive map canvas — the visual, pan-and-zoom Google Map — relies on Google Maps' built-in keyboard support, which is limited. We do not consider the map canvas itself to be the primary path for keyboard or screen reader users.
Instead, the Browse Locations panel is the designed accessible alternative. It contains every location on the map as a scrollable, searchable text list, complete with names, addresses, descriptions, and categories. Visitors can find, read, and navigate every location on the map without ever interacting with the map canvas.
This is intentional. The list gives visitors who use screen readers, keyboard navigation, or other assistive technology a complete, reliable path through the map content — not a degraded fallback.
A screen-reader-only announcement at the top of the page surfaces this path immediately. It reads as a direct link — "Browse all [X] locations as a text list" — and is the first focusable element a keyboard or screen reader user encounters.
Keyboard Navigation
Every interactive element outside the map canvas is operable by keyboard alone.
The "Browse all locations" skip link is the first Tab stop, letting keyboard users reach the location list immediately
Filter chips (category, tag, likes, check-in) respond to Tab, Enter, and Space — they are focusable and activatable without a mouse
The Browse Locations toggle button is keyboard accessible
Location cards in the list are navigable by keyboard
On desktop, selecting a location in the list opens a detail panel alongside the list — the list remains open so users keep their place
On mobile, selecting a location shows full details inline with a "Back to list" button — users return to the same list position without losing context
The header controls (search, share, print, bookmark) are keyboard accessible
The "View on Map" button in location cards lets users move from the list to the spatial view when they choose to
Screen Reader Compatibility
The experience is built with semantic HTML and ARIA attributes to support screen readers such as JAWS, NVDA, and VoiceOver.
The map container carries
role="application"and anaria-labelthat identifies the map by name and tells users how to access the text listFilter chips use
role="button",aria-label,aria-pressed(for toggle state), andaria-expandedwhere applicable, so screen readers announce their current stateModal dialogs — email capture popups, offer overlays — include
role="dialog"andaria-modal, move focus inside on open, return focus to the triggering element on close, and close with EscapeError messages and form validation use
role="alert"witharia-liveso screen readers announce problems without requiring focus to moveFor challenge and scavenger hunt maps, the list view correctly shows clue cards in place of hidden location details — game integrity is maintained without exposing hidden content
Page language is set dynamically via the
langattribute when translation is active
Visual Design
Focus indicators are visible on all interactive elements during keyboard navigation
Category markers on the map use both color and distinct icons — not color alone — so the visual distinction does not depend on color perception
All text is rendered as HTML — no images of text
Zoom is fully enabled on mobile — the map page does not restrict pinch-to-zoom
Admin Settings That Affect Accessibility
The accessible path through your map depends in part on how you have configured it. Some settings directly affect whether keyboard and screen reader users can access your locations. This section describes the choices that matter most.
Critical Settings — Do Not Disable These
Setting | Why It Matters |
Browse Locations panel | This is the only way keyboard and screen reader users can access your location list on desktop. Hiding it removes their primary accessible path. |
List button | Disables the text list of locations entirely. Screen reader users have no alternative way to browse locations. |
Search button | Removes keyboard-accessible search. Visitors who cannot visually scan the map depend on search to find specific locations. |
Header | On desktop, the header contains the Browse Locations button. Hiding the header removes this control from the page. |
If your organization needs to demonstrate accessibility compliance, keep all four of these enabled.
Settings That Improve Accessibility
Use the Standard map style. The admin map style picker labels the Standard (Google Maps default) style as "Best for accessibility." It has the highest contrast road labels and the clearest visual hierarchy of any available style. Night, Spooky, and Fireworks themes have lower contrast and are not recommended when accessibility is a priority.
Pay attention to the color contrast warning. The admin color picker shows a live warning when your selected brand colors fall below the 4.5:1 contrast ratio required by WCAG 2.1 AA for body text. Heed this warning. If you dismiss it and publish with low-contrast colors, the text your visitors read — location names, descriptions, filter labels — may be difficult or impossible to read for visitors with low vision.
Fill in location details completely. Screen reader users cannot see the pin on the map. They hear the name, address, and description you provide in the location editor. A location named "Coffee Shop" with no address and no description gives a screen reader user nothing to work with. A location with a complete address, a description of what to expect, hours, and category tags gives them everything a sighted visitor gets from seeing it on the map.
Enable search. Search lets keyboard users find a specific location by typing rather than tabbing through an entire list.
What Good Configuration Looks Like
For an organization that needs to be able to demonstrate accessibility compliance, the recommended configuration is:
Browse Locations panel: visible
List button: enabled
Search button: enabled
Header: visible
Map style: Standard
Brand colors: passing the contrast checker (4.5:1 minimum for text)
Location records: complete names, addresses, and descriptions
Known Limitations
We believe in being straightforward about where accessibility depends on participant hardware, third-party infrastructure, or areas where we are still improving.
The map canvas itself
The interactive map canvas — the pins, pan controls, and zoom — is powered by Google Maps. Google Maps' built-in keyboard and screen reader support for individual markers is limited. Proxi has intentionally designed the Browse Locations text list as the accessible alternative so visitors are not dependent on the map canvas to access location information. We do not currently expose individual map pins as keyboard-navigable elements beyond Google Maps' default behavior.
Category markers on the map canvas
While location list entries include category names as text, the visual markers on the map canvas itself are visual-only. The list view is where category information is available as accessible text.
Some map styles have lower contrast
The Night, Spooky, and Fireworks map styles are designed for visual appeal and do not meet the contrast standards of the Standard style. Admins who choose these styles are accepting a tradeoff in readability for users with low vision.
Check-in and geolocation features for challenges
QR code check-in requires camera access. Geolocation check-in requires GPS access. These features rely on device hardware and operating system permissions. Participants using assistive technologies or devices without camera or GPS access may find these flows challenging. Organizers running challenges should consider whether alternate check-in methods are appropriate for their event.
Photo uploads for challenges
Some challenge activities require photo submission. This requires access to a camera or photo library and may pose a barrier for some participants. Organizers can choose which activities require photos and may wish to offer alternatives.
Admin portal
This statement covers the visitor-facing map experience only. Accessibility improvements to the Proxi admin portal are ongoing and will be documented separately.
What We're Working On
Accessibility is an ongoing commitment. Here is where we are actively investing:
Expanding keyboard navigation for individual map markers on the map canvas
Evaluating automated accessibility testing as part of our development and release process
Continuing to audit map experience flows as we add new features
Feedback and Accommodation Requests
If a visitor to your map encounters a barrier, we want to hear about it.
Contact Proxi support through the chat widget in your Proxi dashboard, or reach out to your account contact directly.
Organizers who need to support specific accessibility accommodations for their district, event, or destination are encouraged to reach out — we can help you understand your options and plan accordingly.
Technical Reference
Standard | Target Level |
WCAG | 2.1 Level AA |
Keyboard operability | WCAG 2.1 Success Criteria 2.1.1, 2.1.2 |
Focus visible | WCAG 2.1 Success Criterion 2.4.7 |
Name, Role, Value (ARIA) | WCAG 2.1 Success Criterion 4.1.2 |
Status messages | WCAG 2.1 Success Criterion 4.1.3 |
Contrast (minimum) | WCAG 2.1 Success Criterion 1.4.3 |
Language of page | WCAG 2.1 Success Criterion 3.1.1 |
Images of text | WCAG 2.1 Success Criterion 1.4.5 |
Non-text contrast (icons, focus) | WCAG 2.1 Success Criterion 1.4.11 |
Use of color | WCAG 2.1 Success Criterion 1.4.1 |
Resize text | WCAG 2.1 Success Criterion 1.4.4 |
Last updated: March 2026. This statement will be reviewed and updated as the map experience evolves.
A note on using this document with city officials or legal reviewers: This statement is intended to describe Proxi's current implementation honestly. It is not a legal certification. Organizations with specific ADA compliance requirements should consult with an accessibility specialist to assess their full program — including any communications, printed materials, in-person signage, and event logistics that fall outside the Proxi platform.