Accessibility at OrgHQ
An association exists for all of its members. The member who uses a screen reader, the one who can’t use a mouse, the one reading on a cracked phone at 200% zoom — each of them has to be able to join, register for an event, renew, and find what the board posted. So accessibility isn’t a setting in OrgHQ or a project we finished once. It is part of how every page is built, and it is checked automatically before every release.
The standard
We build to the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA — the standard named by the U.S. Department of Justice’s 2024 rule for state and local government websites, and the one most accessibility questionnaires ask about. It applies to everything OrgHQ hosts: this site, every association’s public site, the member hub, and the admin your board uses.
How it is checked
- Every release, in a real browser. Before any change ships, an automated check opens about 90 real pages — public sites, join and registration forms, the member hub, and the admin — and tests each against WCAG 2.1 AA with axe, the industry-standard accessibility engine. It also re-checks every page at a 320-pixel-wide screen (the equivalent of 400% zoom) and with enlarged letter, line, and paragraph spacing. If any page fails, the release doesn’t go out.
- Rules in the code itself. Further checks run on every change: every page has a skip link and a single main region, every form field has a label, pinch-zoom is never disabled, keyboard focus is always visible, and every message that appears without a page change — “Copied,” “Image added,” a sign-in error — is announced to screen readers.
- The main journeys, end to end. Joining, signing in to the member hub, and registering for an event are walked through the way a screen reader sees them: one page title, one main region, and a clearly named button to finish.
What that means for your members
- Your brand color can’t make a page unreadable. Pick any color — even pale yellow — and wherever it is used for text or behind white text, OrgHQ darkens it just enough to meet the WCAG contrast minimum, on white, on the grey page, and on its own tints. No association can configure its way into a contrast failure.
- Keyboards and screen readers. Pages use standard links, buttons, and form fields rather than custom widgets, with labeled fields, a heading outline that never skips a level, and error messages tied to the field they describe.
- Phones and zoom. Every page reflows to a narrow screen without sideways scrolling, and nothing stops a member from zooming in.
- No passwords. Members sign in with a six-digit code sent by email. There is nothing to memorize, and a likely typo in an email address (“gmial.com”) is pointed out before the code is sent.
What your association controls
OrgHQ makes the site accessible; what your board writes on it is yours. The editor asks for a description of every image you add and keeps your headings in order for screen readers, but some things only a person can do:
- Write image descriptions that say what matters in the picture, not “image1.jpg.”
- Caption the videos and recordings you post, and share slides in an accessible format.
- Give links meaningful words (“Register for the fall conference,” not “click here”).
- Check that files you upload, such as PDFs, are accessible themselves.
Where we are still working
Automated testing catches a great deal, but not everything. OrgHQ has not yet been audited by a person using a screen reader (such as NVDA or VoiceOver) from start to finish. That audit is our next step, and we will update this page with what it finds. Until then, we describe our screen-reader support as tested by automation, not verified by a human.
Content that associations upload — documents, videos, embedded payment pages from Stripe — is outside what our checks can test.
For procurement and grant applications
Universities, hospitals, public agencies, and funders often ask for an accessibility conformance report (VPAT) or a completed questionnaire. Ask us and we will answer criterion by criterion — including the ones where the honest answer today is “partially supports.”
Found a barrier? Tell us.
If anything on OrgHQ or on a site we host keeps you from doing what you came to do, please contact support and tell us the page and what happened. We read every report, we treat accessibility problems as bugs to fix rather than feature requests, and we reply within one business day (Mon–Fri, 9am–5pm US Eastern). If you’re a member of an association, you can also tell the association — they can reach us directly.