Accessibility statement
OmniPDF is committed to making its tools and content accessible to everyone, regardless of ability or assistive technology.
Our commitment
We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA standard. This means we aim to ensure that:
- Content is perceivable — text has sufficient colour contrast, images have alt text where informative, and time-based media has captions.
- Content is operable — every control is reachable and usable via keyboard alone, without requiring a mouse.
- Content is understandable — labels are clear, errors are specific, and language is defined.
- Content is robust — it works with current and future assistive technologies.
What we do
- Semantic HTML. We use proper heading hierarchy (one H1, ordered H2s), landmarks (header, nav, main, footer), and lists for list content.
- Keyboard accessibility. Every interactive control can be reached with the Tab key and activated with Enter or Space. Focus indicators are always visible.
- Screen reader support. Status messages are announced via ARIA live regions. Form labels are associated with their inputs. Buttons have accessible names.
- Colour and contrast. Body text meets or exceeds 4.5:1 contrast ratio. Interactive elements meet 3:1 for text or are visually distinguished by other means.
- Reduced motion. Animations respect the user's prefers-reduced-motion setting. Transitional animations are suppressed when motion is disabled.
- Resizable text. The site remains usable at 200% zoom on desktop and 400% text size on mobile.
- No keyboard traps. You can always navigate away from any control using the Tab key or Escape.
- Touch targets. Interactive elements are at least 24×24 CSS pixels, with larger targets for primary controls.
Known limitations
Some tools have inherent accessibility challenges that we have not yet fully resolved:
- PDF preview rendering. The canvas-based preview is visual only. We provide text descriptions but the preview itself is not accessible to screen readers.
- Drag-and-drop reordering. Where drag-and-drop is used (Organize PDF, Sign PDF), we provide arrow buttons as an alternative for keyboard users.
- Canvas drawing tools. The Draw on PDF and Sign PDF tools rely on pointer input. Keyboard users can upload a pre-made signature image instead.
- Large file processing. When a tool takes more than a few seconds, progress is announced via ARIA live regions but the visual progress bar is not itself interactive.
We continue to improve these areas with each release.
Testing
OmniPDF is tested with the following assistive technologies:
- Screen readers — NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
- Keyboard only — tested without using a mouse.
- Zoom — tested at 200% on desktop, 400% text size on mobile.
- Colour blindness simulation — tested with deuteranopia, protanopia and tritanopia simulators.
- High contrast mode — tested with Windows High Contrast Mode.
Feedback
If you encounter an accessibility barrier on OmniPDF, please tell us. Email accessibility@omni-pdf.pages.dev with:
- The page or tool where the problem occurs.
- What you were trying to do.
- What assistive technology you were using (if any).
- A description of what went wrong.
We aim to respond within 5 business days and address accessibility issues in our next release when feasible.
Enforcement
If you are not satisfied with our response, you may contact your local accessibility or disability rights authority. We are committed to cooperating with any such body.
Standards and references
- WCAG 2.2 (W3C Recommendation)
- WAI-ARIA Authoring Practices
- Section 508 (US federal accessibility requirements)
- EU Web Accessibility Directive
Last updated: 1 January 2025