Accessibility

Last updated: April 15, 2026

Our target

SocietyPress aims for conformance with WCAG 2.1 Level AA across both the plugin's admin interface and the public-facing pages it renders. We're committed to that standard for three reasons:

• Society members span every age and ability. Genealogical research is a passion that attracts people from every walk of life. Your members deserve a website they can actually use.
• Volunteer administrators deserve the same. The people running your society's website are often retirees, people with variable vision, and people using older hardware or screen magnification. The admin interface has to work for them too.
• Accessible software is better software. The same design decisions that help people with disabilities — clear headings, strong color contrast, meaningful labels — also make the software easier for everyone.

What we've done

• Semantic HTML throughout — actual headings, actual lists, actual landmarks.
• Keyboard navigation for every interactive element on the public pages and every admin screen.
• Focus states that are visible, not suppressed.
• Color contrast checked against WCAG AA for body text and UI controls.
• Form labels associated with inputs; no placeholder-only fields.
• Announcement bars and modals use appropriate ARIA roles and are dismissible.
• The plugin's design panel lets every society customize colors — so if the default palette doesn't work for your audience, you can adjust it without touching code.
• Vanilla JavaScript only — no frameworks that bury accessibility behind abstractions.

Where we're not there yet

We believe in naming our known gaps:

• Screen reader testing is not exhaustive. We test with VoiceOver on macOS regularly, but NVDA and JAWS coverage is lighter. Reports from screen-reader users are especially welcome.
• The page builder drag-and-drop is mouse-primary. Keyboard alternatives exist for every widget action (you can reorder widgets via the “Move up / Move down” buttons), but the drag interaction itself assumes pointer input.
• Some admin data tables are dense. WP_List_Table bulk-action checkboxes and sort arrows are WordPress core defaults, and their accessibility is only as good as core's. We avoid building on top of them where we can.
• PDF newsletter previews depend on the uploaded PDF being accessible. We can't fix source documents, but we do display member-readable text alternatives where they exist.

How to report an issue

If you hit an accessibility barrier on this website or inside a SocietyPress admin interface, please tell us. A short email is more valuable than a polished bug report — we'd rather know than not.

Email: accessibility@getsocietypress.org

Include anything you can: the page URL, what you were trying to do, what happened, and (if you're comfortable sharing) the assistive technology you're using. We aim to reply within two business days and will credit you if you'd like to be credited.

Compliance

This statement is provided as a voluntary accessibility commitment. SocietyPress is free software distributed under the GPL v2 with no warranty, and this statement does not create any contractual obligation. That said, we take this seriously, and if a society running SocietyPress faces accessibility compliance requirements (ADA, Section 508, EN 301 549), we'll do what we can to help.