Early Tree

Accessibility Statement

Last updated: 1 December 2024

Our Commitment to Accessibility

Early Tree is committed to ensuring that all of our digital services — including our websites, web applications, and mobile applications — are accessible to as many people as possible. We believe that everyone should be able to use our Services regardless of disability, assistive technology, or the device they are using.

This accessibility statement applies to all digital services provided by Early Tree, including:

  • Our marketing website (earlytree.co.uk)
  • The Early Tree Nursery Management System (web and mobile app)
  • Inspector Who (web application)
  • The Early Years Funding Portal (web and mobile app)

We are continually working to improve the accessibility of our Services. If you encounter any barriers, please let us know — your feedback is important to us.

Applicable Standards

We aim to meet the following accessibility standards across our web and mobile platforms:

  • WCAG 2.2 Level AA: We target conformance with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA for all our websites and web applications. WCAG 2.2 is the current internationally recognised standard for web accessibility, covering four core principles: Perceivable, Operable, Understandable, and Robust (POUR).
  • EN 301 549: Our web services are designed to comply with the European standard for digital accessibility (EN 301 549 v3.2.1), which incorporates WCAG 2.1 Level AA and includes requirements for non-web software and mobile applications.
  • Apple Human Interface Guidelines (Accessibility): Our iOS app is designed in accordance with Apple's accessibility guidelines, supporting VoiceOver, Dynamic Type, and other native iOS accessibility features.
  • Android Accessibility Guidelines: Our Android app is designed to support TalkBack, font scaling, display size adjustments, and other Android accessibility features in line with Google's Material Design accessibility guidance.
  • Public Sector Bodies Accessibility Regulations 2018: Where applicable, we comply with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Conformance Status

Our current conformance status for each service is as follows:

Service Status Standard
Marketing website (earlytree.co.uk) Substantially conformant WCAG 2.2 Level AA
Nursery Management System (web) Partially conformant WCAG 2.2 Level AA
Nursery Management System (iOS app) Partially conformant EN 301 549 / Apple HIG
Nursery Management System (Android app) Partially conformant EN 301 549 / Android Accessibility
Inspector Who (web) Substantially conformant WCAG 2.2 Level AA
Early Years Funding Portal (web and mobile) Partially conformant WCAG 2.2 Level AA / EN 301 549

"Substantially conformant" means the vast majority of content and functionality meets the standard, with only minor or isolated non-conformances. "Partially conformant" means some areas of the service do not fully meet the standard, and we are actively working to address these.

What We Have Done to Improve Accessibility

Web and Web Applications

  • Semantic HTML: We use proper heading hierarchies (H1–H6), landmark regions, and semantic HTML5 elements to ensure content is meaningfully structured for screen readers and other assistive technologies
  • ARIA attributes: We use ARIA (Accessible Rich Internet Applications) roles, states, and properties where native HTML semantics are insufficient, particularly for interactive components such as modals, dropdowns, and live regions
  • Keyboard navigation: All interactive elements — including buttons, links, form controls, and modals — are fully operable via keyboard alone. We provide visible focus indicators that meet WCAG 2.2 requirements
  • Colour contrast: We maintain colour contrast ratios of at least 4.5:1 for normal text and 3:1 for large text, in accordance with WCAG 2.2 Level AA Success Criterion 1.4.3
  • Focus appearance: In line with the new WCAG 2.2 Success Criterion 2.4.11, we ensure focus indicators are sufficiently visible and have an adequate area
  • Text alternatives: All meaningful images include descriptive alt text. Decorative images are marked with an empty alt attribute so screen readers skip them
  • Responsive and reflow design: Our layouts reflow appropriately at 320px viewport width without horizontal scrolling, supporting users who zoom to 400% (WCAG 1.4.10)
  • Text resize: Text can be resized up to 200% without loss of content or functionality
  • Error identification: Form errors are clearly identified and described in text, and suggestions for correction are provided where possible
  • Skip links: A "skip to main content" link is provided at the top of each page, allowing keyboard and screen reader users to bypass repetitive navigation
  • No time limits: Where time limits exist for security purposes (such as session timeouts), users are warned in advance and given the option to extend their session
  • No content that triggers seizures: We do not publish content that flashes more than three times per second

Mobile Applications (iOS and Android)

  • VoiceOver (iOS) and TalkBack (Android): All screens and interactive elements in our mobile apps are labelled and navigable via screen readers. We use appropriate content descriptions and accessibility labels throughout
  • Dynamic Type / font scaling: Our iOS app supports Dynamic Type, allowing text to scale according to the user's preferred font size settings. Our Android app respects the system font size setting
  • Touch target sizing: All interactive touch targets meet a minimum size of 44×44 points (iOS) / 48×48dp (Android) to support users with motor impairments
  • Sufficient colour contrast: We maintain the same contrast ratio standards on mobile as on web
  • Reduce Motion: Where animations are used in our mobile apps, we respect the iOS "Reduce Motion" and Android "Remove animations" accessibility settings
  • Switch Control (iOS) and Switch Access (Android): Our apps are navigable using switch access devices for users with severe motor impairments
  • Display Accommodations: Our apps function appropriately with Bold Text, Increased Contrast, and Differentiate Without Colour settings enabled
  • Offline and low-bandwidth accessibility: Key functionality remains available offline and in low-bandwidth conditions, with clear status indicators provided

Known Limitations and Planned Improvements

Despite our ongoing efforts, the following known limitations exist. We are actively working to resolve them:

  • Complex data tables (web apps): Some data-heavy tables in our management dashboards do not yet include full ARIA table markup for screen reader navigation. We are working to add appropriate row and column headers and summary descriptions.
  • PDF documents: Some PDF documents generated by our Services (such as reports and registers) may not be fully accessible as tagged PDFs. We are working to improve PDF accessibility in future releases.
  • Data visualisations and charts: Some charts and graphical data representations do not yet have fully equivalent text or tabular alternatives. We are adding accessible data table alternatives to all charts.
  • User-generated content: Content uploaded by users (such as photos, documents, and observations) may not meet accessibility standards. We encourage users to provide alt text where available.
  • Third-party embedded content: Some content provided by third-party integrations (such as embedded maps or payment widgets) may not fully meet WCAG 2.2. We work with our providers to improve this where possible.
  • Mobile app complex interactions: Some advanced features in our mobile apps (such as drag-and-drop interfaces) are not yet fully accessible via switch control. We are developing keyboard and gesture-based alternatives.

Assistive Technologies We Test With

We test our Services regularly with the following assistive technologies:

  • Screen readers (web): NVDA with Firefox, JAWS with Chrome, and VoiceOver with Safari on macOS
  • Screen reader (iOS): VoiceOver with Safari
  • Screen reader (Android): TalkBack with Chrome
  • Screen magnification: Windows Magnifier, macOS Zoom, and browser zoom to 400%
  • Voice control: Dragon NaturallySpeaking (web), Voice Control on iOS
  • Keyboard-only navigation: All platforms, without mouse input
  • High contrast modes: Windows High Contrast, macOS Increase Contrast

Testing Methodology

Our accessibility testing approach combines:

  • Automated testing: We use automated accessibility scanning tools (including axe-core and Lighthouse) integrated into our development and CI/CD pipeline to catch common accessibility issues early
  • Manual testing: Our development and QA teams perform manual accessibility testing against WCAG 2.2 success criteria as part of the release process for new features
  • Assistive technology testing: We test key user journeys with screen readers, keyboard navigation, and other assistive technologies before significant releases
  • User feedback: We actively review accessibility feedback reported by users and address issues on a priority basis

Disproportionate Burden

We do not currently claim any exemptions from accessibility requirements on the basis of disproportionate burden. We are committed to addressing all known accessibility issues through our regular product development cycle.

How to Request Accessible Alternatives

If you encounter content on our Services that is inaccessible to you, please contact us and we will:

  • Acknowledge your request within 2 working days
  • Aim to provide the information or functionality in an accessible alternative format within 5 working days
  • Log the issue for resolution in our development roadmap

Please provide the following information to help us respond quickly:

  • A description of the accessibility barrier you encountered
  • The URL of the page or the name of the screen in the mobile app where you encountered the issue
  • The assistive technology or browser you were using (if applicable)
  • Your preferred format for an accessible alternative, if relevant

Contact Us About Accessibility

To report an accessibility issue or request accessible content, please contact us:

Email: hello@earlytree.co.uk
Contact form: earlytree.co.uk/contact

We aim to respond to all accessibility enquiries within 5 working days.

Enforcement and Escalation

If you are not satisfied with our response to your accessibility complaint, you may contact the relevant enforcement body:

  • Equality and Human Rights Commission (EHRC): The EHRC is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 in England, Scotland, and Wales.
  • Equality Advisory and Support Service (EASS): If you are unhappy with our response, you can contact the EASS for further advice and support.
  • Disability Rights UK: For general advice and support on disability rights and accessibility, visit disabilityrightsuk.org.

Technical Information

Our Services are built using the following technologies relevant to accessibility:

  • Web: HTML5 (semantic markup), CSS3 with Tailwind CSS, minimal vanilla JavaScript, ASP.NET Core (server-side rendering)
  • iOS: Swift, UIKit and SwiftUI with native accessibility APIs (UIAccessibility)
  • Android: Kotlin, Jetpack Compose and View-based UI with native accessibility APIs (ViewCompat accessibility)

Date of This Statement

This statement was prepared on 1 December 2024 and will be reviewed and updated at least annually, or following significant changes to our Services.