Accessibility
Built accessible from day one.
We built accessibility in because our users built this sector -- not because a checklist told us to. Every feature, every page, every interaction is designed to work for board members with disabilities.
Why accessibility is our core differentiator.
Nonprofits include board members who are themselves people with disabilities -- self-advocates, family members, and community leaders who use assistive technology every day. A board portal that isn't accessible is a board portal that excludes your most important voices.
The major competitors -- Boardable, BoardEffect, OnBoard -- treat accessibility as a compliance checkbox. They may pass an axe scan, but they haven't been tested with actual screen reader users navigating actual board governance workflows.
Accessibility is built in as a first-class requirement from the start -- not retrofitted after launch. When we find gaps, we fix them before the next release, not in the next fiscal year.
Assistive technology support
- VoiceOverMac & iOS
Designed for compatibility across all pages and interactive components.
- NVDAWindows
Built with NVDA compatibility as a design requirement.
- JAWSEnterprise Windows
Enterprise screen reader support is a first-class requirement.
- Keyboard onlyAll platforms
Every task designed to be completable without a mouse
WCAG 2.1 conformance summary
Key success criteria tested and verified. Full VPAT available on request.
| Success Criterion | Level | Status | Notes |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Passes | All images have meaningful alt text or aria-label. Decorative images use alt="". |
| 1.3.1 Info and Relationships | A | Passes | Semantic HTML throughout. Tables, headings, and lists properly marked up. |
| 1.4.1 Use of Color | A | Passes | No information conveyed by color alone. Icons and text reinforce all status indicators. |
| 1.4.3 Contrast (Minimum) | AA | Passes | 4.5:1 for normal text, 3:1 for large text and UI components. |
| 1.4.4 Resize Text | AA | Passes | All content readable at 200% zoom without loss of functionality. |
| 1.4.11 Non-text Contrast | AA | Passes | All interactive component boundaries meet 3:1 contrast ratio. |
| 2.1.1 Keyboard | A | Passes | All functionality operable via keyboard. No keyboard traps. |
| 2.4.3 Focus Order | A | Passes | Logical focus order throughout all pages and dialogs. |
| 2.4.7 Focus Visible | AA | Passes | All interactive elements have a visible focus indicator. |
| 3.1.1 Language of Page | A | Passes | lang="en" set on all pages. |
| 4.1.2 Name, Role, Value | A | Passes | All form controls, buttons, and interactive components have accessible names. |
| 4.1.3 Status Messages | AA | Passes | Status messages announced to screen readers via aria-live regions. |
Last tested: June 2026. For the full VPAT or to report an accessibility issue, contact accessibility@livehelm.com.
Plain-language mode for all AI content.
AI-generated agendas, minutes, and summaries can be displayed in plain language at the click of a button. No jargon, shorter sentences, clearer structure -- essential for board members with cognitive disabilities or those who prefer plain language.
See accessible board governance in action.
Book a demo and we'll walk through accessibility features specifically.