Accessibility Statement

Our commitment

Revel Sphere aims to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA across the website, revelsphere.org, and the organization websites and embeddable widgets it serves. That level is our floor, not our ceiling: a change that would land below it does not ship, and a screen that passes is still read on a phone, by keyboard, and with a screen reader before it does.

This statement is written for two readers: a community member who has met a barrier and wants it fixed, and an accessibility office deciding whether to bring Revel Sphere to its campus, county, or network. Both get the same facts.

What every screen is held to

These are the rules our design and engineering work follows. They are written into the project itself, so a new feature inherits them rather than earning them later.

• Contrast. Text sits at 4.5 to 1 against its background or better (3 to 1 for large text), and controls and icons at 3 to 1. Colors come from an audited token palette, so a new screen inherits combinations that already pass.

• Color is never the only signal. An error, a success, a selected state, or a disabled control is also marked by an icon, a label, a weight, or an underline.

• Keyboard. Every interactive element is reachable with Tab in the order it appears on screen, with a visible focus ring. Dialogs and drawers hold focus while open, close on Escape, and return focus to the control that opened them.

• Touch targets. Anything you can tap is at least 44 by 44 pixels, with 8 pixels between neighboring targets, on chips and icon buttons as well as primary buttons.

• Motion. Animations respect the reduce-motion setting on your device. Nothing moves to convey information on its own, and nothing plays or scrolls by itself.

• Forms. Every input has a label. Errors appear inline, next to the field, and are announced to screen readers. Required fields are marked, and you can always attempt a submission to hear what is missing.

• Structure. Real headings, landmarks, lists, buttons, and links rather than styled boxes. One main heading per page, a skip link to the main content, and a declared page language.

• Images and icons. Meaningful images carry text alternatives; decorative ones are hidden from screen readers. Icons that act as buttons carry a spoken name.

• Status messages. Confirmations, saves, and errors that appear after an action are announced through a live region, so they reach a screen reader without moving focus.

• Phones first. Every screen is laid out for a 375 pixel wide phone with the keyboard open before it is widened for larger screens. Text inputs are at least 16 pixels so phones do not zoom on focus, and nothing scrolls sideways.

How we check

• Automated checks on every change. Our test suite runs axe-core against the public pages and the sign-up, event, sphere, and organization flows, at a desktop width and at an iPhone width, with the WCAG 2.0 and 2.1 A and AA rule sets. A serious or critical finding fails the build.

• A phone pass in the same change. A screen or copy change is reviewed at 375 by 667 and 390 by 844 pixels, with the software keyboard open, as part of the same pull request. Inputs stay visible while typing; controls stay thumb-sized.

• A keyboard pass. New flows are tabbed through end to end before they ship. Anything that cannot be reached or operated is fixed first.

• Contrast checks for new colors. A new color combination is measured before it enters the palette. Raw colors outside the palette are not used for text.

• Screen reader checks on the critical paths. Sign-up, RSVP, and creating a sphere are checked with a screen reader when a change touches them.

Where we still fall short

We would rather name a gap than have you find it. These are the limitations we know about today, and what stands in for each.

• No independent audit yet. Our conformance claim rests on our own evaluation and the automated checks above. We have not yet commissioned a third-party audit, so in the language of a VPAT the platform partially supports WCAG 2.2 AA. A self-evaluated VPAT is available on request, and we will share the first independent report here when we have one.

• Maps. Event and resource maps are drawn with a mapping library that screen readers handle unevenly. The same places are listed as text on the same page, and the map is never the only way to reach them.

• Generated PDFs. The funder report, the group report, and the flyers download as PDFs that are not yet tagged for structure. The same figures are on the web page they come from, which is accessible, and exports are also available as CSV.

• Payment pages. Card checkout, invoices, and the billing portal are pages hosted by our payment processor, Stripe, and follow Stripe’s accessibility work rather than ours.

• What members post. Photos and flyers shared in a sphere’s feed do not yet have a field for a text alternative, so a screen reader hears only that an image is there. The organization website builder does ask for one on every image. Adding the field to sphere posts is on our list.

• The embeddable widget. An organization can place a Revel Sphere widget on its own website. The widget itself meets the floors above; the page around it belongs to the organization.

• The mobile apps. The Revel Sphere apps for iOS and Android are evaluated separately with each release. This statement covers the website.

Browsers and assistive technology

The website is built for the current and previous major versions of Chrome, Safari, Firefox, and Edge on desktop, and Safari on iOS and Chrome on Android. It is built to work with screen readers (VoiceOver, TalkBack, NVDA, and JAWS), browser zoom to 200 percent, high-contrast and reduce-motion settings, and keyboard-only navigation. It does not depend on a mouse, a touchscreen, color vision, or sound.

Tell us about a barrier

If any part of Revel Sphere is hard to use or does not work with your assistive technology, write to hello@revelsphere.org or call (805) 457-4667. Tell us the page, what you were trying to do, and the browser and assistive technology you use. We reply within five business days with a fix, a date for one, or a way to do the same thing another way in the meantime. A barrier that blocks signing up, RSVPing, or reaching your own sphere is treated as urgent.

If you would rather not write to us directly, anyone can send the same report on your behalf.

For accessibility offices and procurement

Institutions evaluating Revel Sphere can request a VPAT (self-evaluated, ITI VPAT 2.5 WCAG edition), our vendor security and privacy answers, and a walkthrough with a screen reader on a call. Write to hello@revelsphere.org. The Umbrella Plan for institutions and fiscal sponsors is described at revelsphere.org/for-organizations, and our privacy practices at revelsphere.org/privacy.

Standards we reference

WCAG 2.2, level AA (W3C). Section 508 of the Rehabilitation Act, which incorporates WCAG 2.0 AA, and the Americans with Disabilities Act as applied to public-facing web services. The floors above meet or exceed each of these where they overlap.

Keeping this statement current

We review this statement when the platform changes in a way that affects it, and at least once a year. The reviewed date at the top changes with it. Revel Sphere LLC is responsible for the content of this statement.