MapleGather

Accessibility Statement

Last updated

In plain terms: We want everyone — including people who use screen readers, keyboard-only navigation, or high-contrast settings — to be able to use MapleGather. We build to a recognized accessibility standard (WCAG 2.1 Level AA), we check it automatically on every change, and if something doesn’t work for you we want to hear about it.

Our commitment

MapleGather (the “Service”) substantially conforms to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. This is our accessibility baseline across the admin console and the Member-facing portal, and it is a product requirement, not an afterthought. As with any software, we cannot guarantee that every success criterion is met at every moment on every screen; known exceptions are listed under Known limitations below.

Because some of our Organizations serve or are affiliated with government-adjacent entities (public libraries, municipal recreation departments, public university groups), we also aim to support Section 508 expectations, which draw on the same WCAG 2.1 AA criteria.

What that means in practice

Our accessibility work targets the following, which we build to and test for:

  • Screen-reader support — semantic HTML, ARIA labeling, landmark regions on every screen, and aria-live regions for content that updates dynamically. We test against VoiceOver (iOS Safari) and NVDA (Windows Firefox/Chrome).
  • Keyboard operability — every interactive element is reachable and operable by keyboard; no mouse-only paths; visible focus indicators; tab order that matches visual order; a skip-to-main-content link on every page.
  • Color and contrast — we never rely on color alone to convey meaning (status is paired with an icon and a text label). Body text targets a AAA-level contrast ratio (7:1) where the design allows, with WCAG AA (4.5:1) as the floor.
  • Text scaling — usable at 200% browser zoom without layout breakage or content loss.
  • Motion sensitivity — we respect the prefers-reduced-motion setting; no animation gates a user action.
  • Touch targets — a minimum 44 × 44 px target on mobile-first surfaces.
  • Forms — labels are associated with inputs, error messages are associated with their fields, and required fields are indicated with more than color.

How we keep it accessible

In plain terms: We don’t just check accessibility once at launch — automated checks run on every code change, so a regression is caught before it ships.

Accessibility conformance is enforced continuously in our engineering process, not measured only at release:

  • Static checks on every change — a strict eslint-plugin-jsx-a11y configuration flags missing alternative text, invalid ARIA usage, interactive elements that can’t take focus, and unlabeled icon buttons.
  • Automated runtime checks — axe-core accessibility scans run against every route and its declared states, per visual theme (light and dark), on every change.
  • Contrast checks — color-contrast is verified against the design token contract as a unit check, plus the runtime axe contrast scan.
  • Human review — because automated tooling catches only a portion of real accessibility issues (focus order, keyboard traps, screen-reader announcements require human judgment), a reviewer evaluates these on changes to user-facing surfaces.

Known limitations

In plain terms: No product is perfectly accessible on day one, and we’d rather be honest about the gaps than pretend they don’t exist.

Our own product interfaces are tested against WCAG 2.1 AA on an automated basis in our build pipeline (per route, per state, per theme). The known limitations at launch are the areas outside our direct control:

  • Third-party embedded content. Payment fields are provided by Stripe, and map/geocoding views by Mapbox; we do not control the accessibility of those embedded components.
  • Organization-authored content. Content an Organization creates in MapleGather — web pages, email content, uploaded documents, and custom fields — is authored by the Organization, and we cannot guarantee its accessibility (see the boundary note below).
  • Generated PDF documents. Documents the Service generates (for example, receipts, the counter-signed Data Processing Addendum, and data exports) may not be fully tagged for screen readers.

We treat accessibility as an ongoing commitment and will update this section as we identify or resolve limitations.

Organization-authored content — boundary. MapleGather’s WCAG 2.1 AA commitment covers the platform surfaces we design and control. Organizations can create their own content within the Service — web pages, email content, uploaded documents, and custom-field values — and the accessibility of that Organization-authored content is the responsibility of the Organization that creates it. We provide accessible authoring tools and guidance where practicable, but we do not control, and cannot guarantee, the accessibility of Organization-authored content.

Feedback and requests for help

In plain terms: If any part of MapleGather is hard to use with assistive technology, tell us — we treat that as a bug, not a feature request.

If you encounter an accessibility barrier in MapleGather, please contact us at support@maplegather.com. Tell us the page or feature, the assistive technology you’re using, and what didn’t work. We will acknowledge your report and work to resolve it.

← All legal documents