Accessibility Statement

Accessibility Statement (Master Page)
Last updated: 02 February 2026

Legal Hub Registry: /legal
Terms & Conditions: /legal/terms-and-conditions
Privacy Policy: /legal/privacy-policy
General & FPV Safety Disclaimers: /legal/safety-disclaimers

FPV School aims to make its websites and services reasonably accessible to as many users as possible, across different abilities, devices, and assistive technologies.

This is a Master Accessibility Statement for the FPV School ecosystem and is UK-focused (England and Wales). References to "ADA" (Americans with Disabilities Act) may appear in legacy page names, older content, or external discussions. We do not present ADA references as a legal commitment for every property; they are used as part of broader accessibility best-practice framing.

We use WCAG as a practical benchmark for web accessibility across the ecosystem.. WCAG references in brackets (e.g., 2.4.1) are included for transparency to show which WCAG success criteria a measure relates to. They are provided for guidance and prioritisation, and do not constitute a guarantee that every criterion is met on every page at all times.

Where individual FPV School properties maintain short "site entry" versions of an accessibility statement, those pages are intended to point back to this Master page. For the current index of master policies and site-entry links, see the Legal Hub Registry.

1. Our approach

Our target is to meet WCAG 2.2 Level AA for core user journeys and primary page templates, where feasible. "Core user journeys" typically include navigation, search, account/login (where present), and checkout (where present).

We aim to make reasonable improvements over time, with a focus on reducing barriers for users, in line with applicable requirements in England and Wales.

Accessibility is an ongoing process. Some pages, tools, or content areas may not yet meet every criterion, particularly where third-party platforms, embedded media, legacy content, or rapid iteration are involved. When we identify barriers, we prioritise fixes based on severity, frequency, and user impact.

2. Measures we aim for (WCAG-aligned)

The sections below describe practical measures we aim to implement across FPV School properties, where reasonably possible, taking into account the property's design, features, and third-party components.

WCAG references in brackets (e.g., 1.1.1) are included for transparency to show which WCAG success criteria a measure relates to. They are provided for guidance and prioritisation, and do not constitute a guarantee that every criterion is met on every page at all times.

2.1 Alternatives (text and media)

We aim to:

• provide meaningful alternative text for non-text content where the image conveys important information (1.1.1);
• provide transcripts where feasible for audio-only or video-only content that we produce and host directly (1.2.1);
• provide captions/subtitles where feasible for videos we produce with important spoken educational content (1.2.2);
• provide additional descriptions where feasible for videos we produce where essential information is conveyed visually and is not already available via the soundtrack (1.2.3, 1.2.5);
• consider live captions for formal live events or webinars we manage, taking into account technical and resource limitations (1.2.4).

Note: Where content is hosted or embedded via third-party platforms (for example, YouTube), accessibility features may depend on the external provider and the capabilities of the embedded player.

2.2 Presentation and structure

We aim to:

• use semantic HTML structure (headings, lists, landmarks) to support assistive technologies (1.3.1);
• present content in a meaningful and logical order (1.3.2);
• avoid instructions that rely only on sensory characteristics such as colour, position, shape, or sound (1.3.3);
• ensure colour is not the only way important information is conveyed (1.4.1);
• avoid auto-playing audio/video where possible, and provide pause/stop/mute controls where media exists (1.4.2);
• aim for readable typography and adequate contrast for text and essential interface elements, aiming towards a contrast ratio around 4.5:1 where feasible (1.4.3);
• support browser zoom and text resizing (up to 200% where practical) without breaking key layout (1.4.4);
• avoid images of text except where essential (for example: equipment interface screenshots) (1.4.5).

2.3 User control and navigation

We aim to:

• support keyboard-only use for essential navigation and interactions (2.1.1);
• avoid "keyboard traps" that prevent users from navigating away from an element (2.1.2);
• where the Services impose time limits, provide reasonable ways to extend or adjust them where practicable (2.2.1);
• provide the ability to pause, stop, or hide moving/auto-updating content where feasible (2.2.2);
• avoid content that flashes more than three times per second (2.3.1);
• include a "Skip to content" mechanism where feasible (2.4.1).

2.4 Understandable content and interaction

We aim to:

• use unique and descriptive page titles (2.4.2);
• maintain a logical focus order and visible focus indicators for interactive elements (2.4.3, 2.4.7);
• use descriptive link text for important actions (2.4.4);
• offer multiple ways to find content where practical (for example: menus, search, indexes) (2.4.5);
• use clear headings and labels (2.4.6);
• declare the primary language in HTML and mark significant language changes where feasible (3.1.1, 3.1.2).

2.5 Predictability and input assistance

We aim to:

• avoid unexpected context changes on focus or input, unless clearly indicated (3.2.1, 3.2.2);
• keep navigation and core components consistent across templates where practical (3.2.3, 3.2.4);
• provide clear error messages and guidance for form fields (3.3.1, 3.3.2);
• provide review opportunities before final submission where feasible (3.3.3, 3.3.4);
• maintain compatible markup and UI components that assistive technologies can interpret reliably (4.1.1, 4.1.2).

2.6 Testing and checks (best-efforts)

We use a practical mix of automated and manual checks, prioritised by impact on real users. Depending on the property and feature set, this may include:

• automated accessibility checks during content and template updates (for example: headings, labels, link text, and common contrast issues);
• keyboard-only navigation checks for key user journeys (navigation, search, account/login where present, checkout where present);
• spot-checks using browser accessibility tools and developer inspections.

Automated tools can highlight common issues but cannot guarantee compliance. Manual review is used to confirm real-world usability where practical.

We also use reports from users to prioritise improvements and to help verify fixes in real-world scenarios where practical.

3. Known limitations

We aim to improve accessibility over time, but some limitations may exist. The list below is non-exhaustive and reflects common areas where accessibility can vary across properties and content types.

3.1 Third-party platforms, embeds, and plugins

Some pages may include embedded or integrated third-party services (for example, YouTube players, external widgets, payment tools, analytics dashboards, community tools, or WordPress plugins). In these cases, accessibility can depend on:

• the external provider's own accessibility features and updates;
• the embedded player/widget controls and keyboard support;
• the way the integration is implemented on a specific property.

Where practical, we aim to choose reputable providers and configure integrations responsibly, but we may not be able to fix limitations that exist inside third-party components.

3.2 Legacy content and historical media

Older content may not fully meet current accessibility best practices, especially where it was created before accessibility improvements were introduced. This can include:

• images missing meaningful alternative text;
• older videos without captions or transcripts;
• older page structures that do not consistently follow current heading/label conventions;
• archived pages that are kept online for reference but are not actively maintained.

We prioritise improvements for high-traffic pages, core journeys, and safety-critical content first.

3.3 Highly technical content (FPV and hardware)

FPV and hardware education often involves dense technical material (diagrams, flight logs, firmware screenshots, CLI outputs, wiring layouts, and rapid troubleshooting notes). Accessible equivalents can take time to produce and may be limited by the nature of the source material.

Where feasible, we aim to:

• add context and explanations in text alongside diagrams or screenshots;
• avoid relying solely on an image to convey essential instructions;
• provide summaries or step-by-step text for key procedures.

3.4 Community and user-generated content (where enabled)

Where community features or user-generated content exist, we cannot fully control how content is authored by users. For example:

• users may post images without alt text;
• formatting may be inconsistent;
• linked external content may not be accessible;
• live discussions may prioritise speed over structured formatting.

We may moderate content for policy and safety reasons, but we cannot guarantee that all user-generated content will meet accessibility standards.

3.5 Downloadable documents and file formats

Some downloadable resources (for example, PDFs, templates, exported logs, or bundled files) may not yet be fully optimised for accessibility, particularly where they originate from third-party tools or rapid publishing workflows.

Where feasible, we aim to provide important information in a web page format or in plain text as an alternative. If you need a document in an alternative format, contact us (see Section 5).

4. Third-party services and content

Some FPV School properties rely on third-party services to deliver core functionality (for example: video hosting, payments, email delivery, analytics, community platforms, customer support tools, spam protection, and embedded widgets).

Where we link to, embed, or integrate third-party services:

• accessibility features and limitations may be determined by the external provider and their software updates;
• embedded players/widgets may not expose full keyboard support or consistent screen-reader labelling;
• we may not be able to modify or remediate accessibility issues that exist within the third-party component itself.

Where practical, we aim to:

• select reputable providers with publicly available accessibility information or statements where possible;
• configure integrations in a way that avoids unnecessary barriers (for example: accessible labels, sensible focus order, and avoiding auto-play where possible);
• offer alternative ways to access important information if a third-party component creates a barrier (for example: providing a text summary, transcript, or direct link to the content).

If you encounter a barrier caused by a third-party tool we use, please report it (see Section 5). Where feasible, we will consider configuration changes, alternative providers, or alternative access methods.

4.1 Assistive technology and browser compatibility (indicative)

We aim for reasonable compatibility with current, standards-based browsers and common accessibility tools. "Compatibility" depends on many factors (device, OS version, browser, extensions, assistive technology, and page complexity), but our practical baseline is:

• current versions of major browsers (Chrome, Safari, Firefox, Edge);
• built-in platform accessibility features and screen readers (for example: VoiceOver on iOS/macOS, and comparable tools on other platforms);
• keyboard navigation as a baseline expectation for core interactions.

We prioritise fixes that improve accessibility for the widest group of users, particularly where an issue blocks a core user journey. We may not be able to support every legacy browser/device combination or highly customised setups, but we will make reasonable efforts to reduce barriers where practical.

If a specific assistive technology or browser combination behaves unexpectedly, please report it (see Section 5) and include your device, OS, browser version, and assistive technology details.

5. How to get help or report an accessibility issue

If you encounter an accessibility barrier, please contact us:
legal@fpvschool.com

If you need information in an alternative format, tell us what would work best (for example, plain text, structured headings, or a transcript).

To help us investigate and resolve the issue faster, please include (where possible):

• the page URL;
• what you were trying to do;
• what went wrong (and what you expected to happen);
• steps to reproduce the issue (what you clicked/typed);
• your device, operating system, and browser (including versions if available);
• any assistive technology you are using (for example, a screen reader or keyboard-only navigation);
• screenshots or screen recordings where relevant.

If the issue relates to an embedded third-party tool (for example, a video player or widget), please mention the tool/provider and the point where the barrier occurs.

We aim to respond in a reasonable time. Response times may vary depending on workload, the complexity of the issue, and whether third-party providers are involved.

6. Improvements and review

Accessibility improvements are handled as part of ongoing maintenance and release cycles across the FPV School ecosystem. We review accessibility in practical ways, for example:

• when we update site templates, themes, or shared components;
• when we launch or redesign key pages and "core user journeys" (navigation, search, account/login where present, checkout where present);
• when we receive credible reports from users (see Section 5);
• when we replace or reconfigure third-party tools that affect usability.

6.1 What we typically improve

Depending on the property and feature set, improvements may include:

• fixing keyboard navigation and focus issues (for example: focus order, missing focus indicators, and traps);
• improving headings, labels, and semantic structure to support assistive technologies;
• addressing contrast and readability issues in primary templates;
• adding or improving alternative text for meaningful images in priority areas;
• adding or improving captions/transcripts for educational media we produce, where feasible;
• reducing unnecessary motion/auto-updating behaviour where it creates barriers;
• refining shared templates and reusable components so improvements scale across multiple properties.

6.2 Prioritisation (how we decide what to fix first)

Where we identify issues, we prioritise based on:

• severity (does it block a core action?);
• frequency (how many users/pages are affected?);
• user impact (how significant is the barrier?);
• effort and risk (can we fix it safely without breaking other features?).

This approach helps us make steady improvements across the wider ecosystem rather than creating isolated fixes that do not scale.

7. Important note (no guarantee)

We make good-faith, reasonable efforts to improve accessibility over time. However, we cannot guarantee that every part of the Services will always be fully accessible, uninterrupted, or fully compliant with every accessibility standard in every context.

Accessibility can vary by property, device, browser, assistive technology, content type (including user-generated content), and third-party components. This statement is provided for transparency and does not create a contractual guarantee beyond what is required under applicable law in England and Wales.

8. Operator

Operator: FPV SCHOOL LIMITED (England and Wales)
Registered office: 483 Green Lanes, London. N13 4BS. United Kingdom.
Company number: 15817837
Contact: legal@fpvschool.com