Accessibility Statement

Last revised: 2026-06-15 · Version: 1.0.0

1. Our commitment

PYLON, operated by PYLON Film Pty Ltd, is committed to making our service usable by the widest possible audience, regardless of disability. We target conformance with Web Content Accessibility Guidelines (WCAG) 2.2 Level AA across our platforms and design new features against that target from the start, not as a retrofit.

This statement is honest about where we are. We have shipped substantial accessibility work and we have known gaps. Both are documented below.

2. Platforms covered

This statement applies to:

• The PYLON web application at app.pylon.video (apps/web, TanStack Router + Tailwind v4 + React 19).
• The PYLON admin application at admin.pylon.video (apps/admin).
• The PYLON marketing site at pylon.video (apps/web shared bundle).
• The PYLON iOS application (Expo SDK 54, apps/mobile).
• The PYLON Android application (Expo SDK 54, apps/mobile).

3. Standards we target

• WCAG 2.2 Level AA, primary target across web and mobile.
• EN 301 549, European Accessibility Act standard, where applicable.
• AS EN 301 549, Australian adoption of EN 301 549.
• §508, US federal accessibility standard, where applicable.
• WCAG 2.2 Level AAA, aspirational on text contrast and motion.

4. Current conformance status

Partially conformant with WCAG 2.2 Level AA. We have substantial automated and manual coverage, with known gaps documented in §5.

Automated coverage

We run axe-core in continuous integration via Playwright. The test files are at:

• tests/a11y-axe.spec.ts, axe-core sweep across 87 routes (current count; sweeps the full route table generated by TanStack Router).
• tests/a11y.spec.ts, page-level smoke for landmark, heading order, alt-text and form-label rules.
• tests/a11y-keyboard.spec.ts, keyboard-only nav verification on the core flows (sign-in, browse, watch, account, submit).

A failing axe rule blocks merge to main. The CI command is bun run test:a11y and is gated on every pull request.

Manual coverage

Manual passes occur on:

• New marketing pages, before launch.
• New playback features (control surfaces, captions UI, watch-party controls).
• New admin tools, before they ship to senior-curator users.
• Any feature reported as inaccessible by a user.

Screen-reader passes are run with VoiceOver (macOS, iOS) and TalkBack (Android). The web app is also tested with NVDA on Windows for critical paths.

5. Known limitations

We tell you about the gaps because we'd rather you know than not:

• Video player. The Mux Player surface is improving but the custom captions menu and quality selector are still under refinement for screen-reader nav. Default captions toggle and play/pause are accessible; deeper menu navigation is the near-term work.
• Watch-party UI. The realtime presence indicators and chat use ARIA live regions, but heavy-traffic rooms can outpace some screen readers. We are tuning the polite-vs-assertive balance.
• Admin tooling. Internal-use surfaces (apps/admin) have a lower polish floor than the public app. Senior curators use a small set of known flows; outside those flows the admin UI may not meet WCAG 2.2 AA. We treat admin findings as Tier-2 and ship them in batches.
• Mobile. The Expo app inherits Tailwind v4 tokens via the shared design-tokens package, and the React Native a11y APIs are wired across the primary navigation. Less-common screens (offline-download manager, payout receipts) are still being audited.
• Filmmaker submission flow. The provenance attestation form is long; we have keyboard nav but the section markup is being refined for predictable screen-reader heading order.

This list is updated when items ship and when new findings come in.

6. Conformance methodology

Our methodology is:

1. Automated sweep on every PR via axe-core / Playwright. A failing rule blocks merge.
2. Manual triage at design time, against a checklist that covers landmarks, heading order, focus order, contrast, alt text, form labels, motion preferences, and reduced-motion handling.
3. Screen-reader pass before any new public-facing feature ships. The pass uses VoiceOver (macOS, iOS) and TalkBack (Android) for the surface in question.
4. Reduced-motion handling for any animation longer than 300 ms or any infinite-loop animation. We honour prefers-reduced-motion at the design-system level.
5. Captions are required for every published title. Submissions without captions are declined under the Editorial Policy.
6. Independent assessment, we plan to commission a third-party accessibility audit. Date is TBD live publication review.

7. Alternative formats and accommodations

If you need information from PYLON in a different format, or if you need an accommodation we don't currently offer, contact [email protected]. We will respond within 5 business days with either the alternative format or a clear timeline for providing it.

Examples of alternative formats we can provide on request:

• Plain-text version of any policy in this /legal/ directory.
• High-contrast version of an interface screenshot.
• Transcript of a published title where the captions are not sufficient.

8. Australian-specific provisions (DDA 1992)

The Disability Discrimination Act 1992 (Cth) requires that goods and services be accessible to people with disabilities. The Australian Human Rights Commission's World Wide Web Access Advisory Notes establish that this includes web services.

PYLON commits to:

• conformance with WCAG 2.2 Level AA as the operational standard;
• a published path to request reasonable accommodations ([email protected]);
• a feedback channel that responds within 5 business days;
• continuous improvement on the gaps in §5.

9. US-specific provisions (ADA + §504)

The Americans with Disabilities Act and §504 of the Rehabilitation Act establish federal accessibility requirements for places of public accommodation and federally-funded programs. While PYLON is not a place of public accommodation in the brick-and-mortar sense, US case law has applied the ADA to commercial websites with sufficient nexus to physical commerce. We treat the ADA standard as binding on our US-facing service.

PYLON does not currently receive federal funding and is not subject to §504 directly, but we use §504-aligned standards as a reference.

10. EU-specific provisions (EAA)

The European Accessibility Act (Directive (EU) 2019/882) establishes accessibility requirements for products and services offered to EU consumers, including audiovisual media services. EAA obligations apply progressively from June 2025 onward.

PYLON's compliance position with respect to the EAA is under review as we enter the EU subscriber market. The standard we target, WCAG 2.2 Level AA, exceeds the EN 301 549 baseline that the EAA references.

11. Reporting an accessibility issue

If you encounter an accessibility issue:

1. Email [email protected] with:
   • the URL or app screen affected;
   • the assistive technology and browser / OS you are using;
   • what happened and what you expected to happen;
   • your preferred contact channel for follow-up.
2. We acknowledge within 24 hours (Mon–Fri, AET).
3. We respond substantively within 5 business days: either with a fix, a workaround, an estimated fix date, or an explanation of why the issue is not actionable.

We track every accessibility issue in our internal ticketing system. Patterns surface in our accessibility roadmap.

12. Continuous improvement

This statement is reviewed at least annually and on any material change to our accessibility posture. We expect to update §5 (known limitations) more frequently than the rest of the document, that list is a moving target.

Related

• Terms of Service
• Privacy Policy

Contact

• Accessibility: [email protected]
• Acknowledgement SLA: 24 hours · Response SLA: 5 business days
• Postal: PYLON Film Pty Ltd, Level 2, 111 Harrington Street, THE ROCKS NSW 2000, Australia

Version history