Accessibility Statement

Our Commitment

Hilston Park is committed to making our website accessible to as many people as possible, including people with disabilities, people who use assistive technologies, and people who depend on keyboard, switch, or voice navigation.

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, published by the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI). These guidelines define how to make web content perceivable, operable, understandable, and robust for people with a wide range of disabilities — including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

We treat accessibility as an ongoing responsibility, not a one-time fix. We are actively working to identify and address gaps, and we welcome feedback from users who encounter barriers on our site.

Conformance Status

The Hilston Park website partially conforms to WCAG 2.2 Level AA. This means that some parts of the content do not yet fully meet the standard. We are actively working to address the specific limitations listed in the Known Limitations section below.

Formal colour contrast testing and a full interactive component audit have not yet been conducted. All other criteria have been assessed through self-evaluation and automated browser tools.

What WCAG 2.2 Level AA Requires

WCAG 2.2 is organised around four principles. Each principle groups the specific requirements (called success criteria) that a website must meet. The following is a summary of Level AA requirements and how they apply to this site.

1. Perceivable — Visual Presentation & Contrast

Users must be able to perceive all information presented on the page regardless of which of their senses they use.

• Colour contrast (1.4.3): Body text and images of text must achieve a minimum 4.5:1 contrast ratio against their background. For large text (18pt or 14pt bold and above), the minimum is 3:1.
• Non-text contrast (1.4.11): User interface components (such as input field borders, checkbox outlines, and focus rings) and meaningful graphical elements must achieve at least 3:1 contrast against adjacent colours.
• Text resize (1.4.4): Users must be able to resize text up to 200% using browser zoom without losing content or functionality.
• Images of text (1.4.5): Text must be rendered as real text in HTML, not as images of text, unless the specific presentation is essential (logotypes are exempt).
• Reflow (1.4.10): Content must reflow at 400% zoom (320 CSS pixels wide) without requiring two-dimensional scrolling.
• Text alternatives (1.1.1): All meaningful images must have descriptive alternative text. Decorative images must be hidden from assistive technologies.
• Input purpose (1.3.5): The purpose of form inputs collecting personal information must be programmatically identifiable so browsers and assistive technologies can autofill or relay context to users.

2. Operable — Navigation & Interaction

Users must be able to operate all interface components and navigate all content.

• Keyboard access (2.1.1): All functionality must be accessible using a keyboard alone, with no keyboard traps.
• Bypass blocks (2.4.1): A mechanism to skip repeated navigation blocks (such as a skip link) must be available on every page.
• Visible focus (2.4.7): A clearly visible focus indicator must be present whenever a user navigates by keyboard.
• Multiple ways (2.4.5): More than one way must be available to locate a page within the site (e.g. navigation menu plus a site search or sitemap).
• Consistent navigation (3.2.3): Navigation menus that repeat across pages must appear in the same relative order each time.
• Focus not obscured — WCAG 2.2 (2.4.11): When an element receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers or cookie banners.
• Dragging movements — WCAG 2.2 (2.5.7): Any feature that requires a dragging gesture must also be operable by a single pointer click or tap, with no dragging required.
• Target size minimum — WCAG 2.2 (2.5.8): Interactive targets (buttons, icons, links) must measure at least 24×24 CSS pixels, or have sufficient spacing so targets do not overlap.

3. Understandable — Readability, Forms & Error Handling

Users must be able to understand both the information and how to operate the interface.

• Page language (3.1.1): The lang attribute on the <html> element must correctly identify the primary language of each page.
• Error identification (3.3.1): When a form error is detected automatically, the field in error must be identified and the error described in text.
• Labels or instructions (3.3.2): Labels or instructions must be provided for all user inputs.
• Error suggestion (3.3.3): Where an input error is detected and a correction is known, a suggestion must be provided to the user unless doing so would compromise security.
• Consistent help — WCAG 2.2 (3.2.6): Help mechanisms (such as contact details or a support link) that repeat across pages must appear in the same relative location on every page.
• Redundant entry — WCAG 2.2 (3.3.7): Information already entered by a user within the same session or process must not be requested again unless re-entry is essential or for security reasons.
• Accessible authentication — WCAG 2.2 (3.3.8): Where a user must authenticate, the process must not rely solely on a cognitive function test (such as remembering a password or solving a puzzle) unless an alternative method or assistance is provided.

4. Robust — Technical Compatibility

Content must be robust enough to be interpreted reliably by current and future assistive technologies.

• Name, role, value (4.1.2): All user interface components must expose their name, role, and current state or value programmatically so assistive technologies can interpret and relay them correctly.
• Status messages (4.1.3): Status messages (such as form submission confirmations or error alerts) must be programmatically determined through role or properties (for example aria-live) so they are announced to screen reader users without requiring focus to move to the message.

Media Requirements

Pre-recorded video content must include audio descriptions for visual elements. Live audio content must provide real-time captions. The Hilston Park website does not currently host embedded synchronised media (pre-recorded video with audio, or live streams). Should video or live audio content be added in the future, captions and audio descriptions will be provided in accordance with WCAG 2.2 criteria 1.2.4 and 1.2.5.

How We Address These Requirements

The following measures are currently in place across the Hilston Park website:

Known Limitations

Despite the measures above, the following known limitations remain. We are actively working to resolve them:

Exceptions — Where Contrast Requirements Do Not Apply

WCAG 2.2 explicitly excludes the following from the colour contrast requirement (criteria 1.4.3 and 1.4.11). These are not limitations; they are specified exceptions in the standard:

Feedback and Contact

We welcome feedback on the accessibility of the Hilston Park website. If you experience a barrier, find something difficult to use, or have a suggestion for how we could improve, please contact us:

• Email: hello@hilstonpark.com
• Phone: +44 (0) 1600 240033
• Contact form: hilstonpark.com/contact

We aim to respond to accessibility enquiries within five working days. If the issue requires development changes, we will provide an estimated timeframe for resolution.

Technical Specifications

The Hilston Park website is built with HTML5, CSS3, and vanilla JavaScript. It does not use any JavaScript framework. The site relies on the following technologies for accessibility:

• HTML5 semantic elements and landmark roles (<header>, <nav>, <main>, <footer>, <section>, <address>)
• CSS3 for layout, responsive behaviour, focus styles, and colour contrast
• Vanilla JavaScript for interactive components: mobile navigation overlay, date picker, cookie banner, and accessibility toolbar
• WAI-ARIA (Accessible Rich Internet Applications) 1.2 roles, states, and properties throughout
• A per-page accessibility toolbar providing font size adjustment, high-contrast inversion, and colourblind simulation filters
• A global skip-to-content link on every page, revealed on keyboard focus

The site is deployed on Vercel with cleanUrls: true, meaning pages are reachable at clean paths such as /accessibility rather than /accessibility.html.

Assessment Approach

Hilston Park assessed the accessibility of this website using self-evaluation and automated browser tools. The specific methods used include:

• Self-evaluation against WCAG 2.2 Level AA success criteria — each criterion reviewed manually by the development team
• Automated browser tools — structural issues including missing alternative text, absent form labels, improper heading hierarchy, and missing ARIA attributes were identified using browser-based accessibility inspection tools
• Keyboard navigation testing — all pages tested for complete keyboard operability, logical focus order, and visible focus indicators
• Screen reader spot-checks — key user journeys reviewed with VoiceOver on macOS and Safari
• Responsive and reflow testing — all breakpoints tested from 320 px upwards

No formal accredited third-party audit has been conducted. We plan to commission an independent evaluation in the future. The W3C provides a full reference at How to Meet WCAG (Quick Reference).

Date of This Statement

This accessibility statement was created in July 2026 and reflects the state of the Hilston Park website at that date. It will be reviewed and updated whenever significant content or structural changes are made to the site, and at least once annually.