Accessibility Statement
Updated · Multi Post Social guide
Multi Post Social aims to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA across the website and the product. Social media tools are used by many people with disabilities, and a tool that helps you publish accessible content should be accessible itself. This statement explains what works today, what does not yet, and how to tell us about a barrier. Last reviewed: October 27, 2026.
1. What works
- Keyboard: every link, button, menu, form and the composer can be reached and operated with a keyboard, in a logical order, with a visible focus outline.
- Structure: one heading per page, landmarks for header, navigation, main content and footer, a skip link to the main content, and breadcrumbs on every page except the homepage.
- Contrast: text and interactive elements meet the 4.5:1 ratio (3:1 for large text), and status is never shown by color alone.
- Forms: every field has a visible label, errors are announced and described in text, and required fields are marked.
- Touch: tap targets are at least 44 by 44 pixels on phones.
- Motion: animations respect the reduce-motion setting of your device.
- Zoom: pages work at 200% zoom and on 320-pixel-wide screens without horizontal scrolling; tables scroll inside their own box.
- Accessible publishing: the composer asks for alt text on every image before a post can be queued and reminds you to add captions to videos, so the content you publish is accessible too.
2. Known gaps
| Area | Issue | Plan |
|---|---|---|
| Calendar drag and drop | Moving a post by dragging has no keyboard equivalent yet | Add a "Move to…" action in the post menu |
| Analytics charts | Charts have text summaries but no per-point screen-reader table | Add a "View as table" toggle under each chart |
| Best-time heat map | Color intensity conveys the value; a numeric table exists only in the export | Show the numeric table on the page |
| Mega menus | Menus open on click, not on hover, which is good; closing with Escape is not yet supported everywhere | Add Escape handling |
| Third-party login screens | Network login pages are outside our control | None possible; we document the step |
3. How we test
We test with keyboard only, with screen readers (NVDA on Windows, VoiceOver on macOS and iOS), with browser zoom and with automated checks in our build. Accessibility issues are tracked like any other bug and listed on the roadmap when they need more than a quick fix.
4. Report a barrier
If something on the website or in the product is hard or impossible for you to use, email [email protected] with the page, what you were trying to do and the assistive technology you use. We reply within two business days, offer a workaround where one exists and tell you when the fix ships.
5. Standards and compatibility
The site is built with semantic HTML, WAI-ARIA where HTML alone is not enough, and tested in the current versions of Chrome, Edge, Firefox and Safari on desktop and mobile. The security guide and the privacy policy are written to the same plain-language standard as this statement.