Skip to main content
SchoolBoardHQ
Accessibility statement
Effective September 1, 2026 · Last updated September 1, 2026
SchoolBoardHQ is committed to providing an accessible experience for board members and other users.
Our accessibility standard
We design and test SchoolBoardHQ against WCAG Level AA accessibility criteria. This is an internal design and testing target, not a claim of independent certification.
SchoolBoardHQ is available on iPhone, Android, and the web. The feature table below is written in iPhone terms because it mirrors Apple's own accessibility questionnaire, but the same underlying design and code apply across platforms — Android and web use the same accessible names, contrast, text-scaling, and reduced-motion handling described here. We have not yet completed a dedicated verification pass against Android TalkBack specifically.
Accessibility features
The table below lines up with the accessibility features Apple asks every app to declare on its App Store product page. It reflects the same information we report there.
Accessibility feature support
VoiceOver
What it means
Navigate and use the app with Apple's built-in screen reader, without needing to see the screen.
SchoolBoardHQ support
Supported. Buttons, links, and form fields on the app’s core screens (Community, People, Messages, Profile) carry accessible names a screen reader can read aloud.
Voice Control
What it means
Navigate and interact with the app by speaking commands like "tap" or "swipe," or by dictating text.
SchoolBoardHQ support
Built for it — Voice Control listens for the same accessible names VoiceOver reads aloud, and the app is designed so those names match what’s on screen. We’re completing a full on-device verification pass before treating that as a blanket guarantee everywhere.
Larger Text
What it means
Increase the app's text size, including to 200% or more, using your device's text-size setting.
SchoolBoardHQ support
Supported. Text follows your device’s text-size setting, and layouts like buttons grow to fit larger text instead of clipping it. A small number of fixed-size elements (tab badges, unread counts) have a size ceiling so they don’t break the layout — see "Known limitations" below.
Dark Interface
What it means
Use a dark color scheme throughout the app to reduce eye strain or light sensitivity.
SchoolBoardHQ support
Supported. Every screen follows a full light/dark theme, including your device's system setting.
Differentiate Without Color Alone
What it means
Understand status and selection states without relying on color perception alone.
SchoolBoardHQ support
Supported. Status indicators (for example, a verified badge or a pinned post) pair color with an icon or text label rather than using color by itself.
Sufficient Contrast
What it means
Read text and icons clearly against their background.
SchoolBoardHQ support
Supported. Core text and button-label color pairs, in both light and dark mode, are held to the WCAG AA 4.5:1 contrast standard and checked automatically, so a future color change can’t quietly fall below it.
Reduced Motion
What it means
Reduce or remove animations that can cause discomfort for people with motion sensitivity.
SchoolBoardHQ support
Supported. When your device’s Reduce Motion setting is on, animated elements — loading indicators, toasts, celebration moments — resolve to their end state instantly instead of animating.
Captions
What it means
Follow video or audio content in the app using synchronized text.
SchoolBoardHQ support
Not applicable right now — SchoolBoardHQ's current release doesn't include app-hosted video or audio content. If that changes, we’ll add caption support and update this page.
Audio Descriptions
What it means
Hear a narrated description of what's happening on-screen in video content.
SchoolBoardHQ support
Not applicable right now, for the same reason as Captions.
Accessibility practices
•
Core color pairs — body text on its background, and every button label on its background, in both light and dark mode — are covered by an automated test asserting WCAG AA contrast; we do not have automated coverage of every color combination that appears in the app.
•
Interactive controls are designed to work with touch, keyboard navigation, and assistive technology (screen reader labels and roles on buttons, links, and form fields).
•
Icon-only buttons and other small tappable controls (share, bookmark, back) are built to a minimum 44-point touch target, even when the visible icon is smaller, so they’re easier to tap accurately.
•
On the web, a "Skip to content" link lets keyboard users jump past repeated header navigation straight to a page’s main content.
•
Forms use persistent labels, instructions, and clear error messages.
•
Text respects your device’s text-size setting up to a per-element limit (for example, up to double size for paragraph text, a smaller ceiling for compact elements like buttons and badges) so larger text stays readable without breaking the layout. This is a deliberate cap, not unlimited enlargement.
•
Meaningful images and icon controls include accessible names; purely decorative icons are hidden from screen readers so they do not add noise.
•
Motion and animation are designed to respect device accessibility preferences.
Known limitations
We test the practices above deliberately rather than claiming full, automatic WCAG conformance. As of this update, known gaps are:
•
Contrast testing covers the core text and button-label pairs above, not every color combination that appears in the app (for example, decorative icon tints against every surface they can sit on).
•
Enlarged text is capped rather than unbounded — see "Accessibility practices" above for the per-element limits. At the largest device text sizes, some fixed-size elements (badges, tab labels) may truncate rather than wrap.
•
We have not run a full manual audit of keyboard focus order and focus-trap behavior across every screen; primary flows (onboarding, forms, modals) have been checked, but coverage is not exhaustive.
•
Some AI-generated content (document summaries) is plain text without additional structure for screen readers beyond standard paragraph semantics.
•
Voice Control is built into the app’s design (see "Accessibility features" above), but we have not yet completed a full pass testing it on a real device end to end.
•
SchoolBoardHQ does not currently include app-hosted video or audio content, so captions and audio descriptions do not apply yet.
•
A photo a member attaches to a Community post opens as a labeled attachment (a screen reader announces its file name) rather than as an inline image with a written description — so you’ll know a photo is attached, but not what it shows, until you open it.
•
This page covers the iPhone app in detail; Android and web share the same underlying design but have not had a dedicated platform-specific verification pass yet (see "Our accessibility standard" above).
If you run into a barrier not listed here, please report it — see "Report an accessibility problem" below. We update this list as we find and fix issues, and remove items once they’re resolved.
Report an accessibility problem
Email support@schoolboardhq.com with the page or feature involved, the device and browser you used, and a description of the problem. Do not include confidential district, student, or personnel information.
If you’re signed in, you can also use the Accessibility feedback form in the app (Settings → Appearance & accessibility → Accessibility feedback). It walks through a few multiple-choice questions instead of writing a full email, and asks a follow-up question tailored to the specific feature you select.
The email address works whether or not you can sign in, so use it for anything that keeps you out of your account or off a screen entirely — including a barrier in signing in itself.
Changes
As we build new features or hear about a barrier, we update this statement. The date at the top of this page reflects the last update.