Accessibility

Our Commitment

IVLAND 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.

‍2. Information We Collect

Partially Conformant — Actively ImprovingInformation You Provide

The IVLAND 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.

WCAG Principle	Status	Notes
1. Perceivable	Partial	Newsletter inputs lack programmatic labels; colour contrast not formally verified
2. Operable	Partial	No site search or sitemap; some small touch targets not verified against 24×24 px minimum
3. Understandable	Meets	Consistent navigation and identification; correct page language; error handling on contact form
4. Robust	Partial	Form submission status messages not verified as ARIA live regions; GTM iframes being updated

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.

WCAG 2.2 vs. 2.1: WCAG 2.2 (published October 2023) extends WCAG 2.1 with six new success criteria at Level A and AA. These additions focus specifically on users with low vision, cognitive limitations, and motor disabilities. All WCAG 2.1 Level AA criteria are included within WCAG 2.2. This statement covers the full WCAG 2.2 Level AA set.

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.
Text alternatives (1.1.1): All meaningful images must have descriptive alternative text. Decorative images must be hidden from assistive technologies.

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.
Bypass blocks (2.4.1): A mechanism to skip repeated navigation blocks (such as a skip link) must be available on every page.
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.
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.

Media Requirements

Pre-recorded video content must include audio descriptions for visual elements. Live audio content must provide real-time captions. The IVLAND 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 IVLAND website:

Perceivable

All meaningful images carry descriptive alternative text following the alt attribute standard
Decorative background images use alt="" and role="presentation" to be skipped by screen readers
The site is fully responsive and designed mobile-first; content reflows correctly at all viewport widths including 320 px
All typography uses relative units (rem and em); text resizes correctly to 200% browser zoom without overflow
No images of text are used for informational content; the IVLAND logo is a logotype (see Exceptions below)
The site does not play audio automatically; no audio content requires volume controls
Colour is not used as the sole means of conveying information, indicating an action, or distinguishing elements
An on-page accessibility toolbar provides high-contrast colour inversion and four colourblind simulation modes (deuteranopia, protanopia, tritanopia, achromatopsia), with preferences saved across sessions

Operable

A skip-to-main-content link is provided on every page; it becomes visible on keyboard focus
All interactive elements — navigation links, buttons, form fields, and the cookie banner — are reachable and operable by keyboard alone
The mobile navigation overlay is dismissible using the Escape key; focus is managed on open and close
Keyboard focus indicators are clearly visible on all interactive elements via :focus-visible styles in the accessibility stylesheet
All pages have unique, descriptive <title> elements
Headings follow a logical hierarchy (h1 → h2 → h3) on all pages
HTML landmark regions (<header>, <nav>, <main>, <footer>) are used throughout
The sticky site header is compact; keyboard-focused elements below it are not entirely obscured (WCAG 2.2 §2.4.11)
No drag-only interactions are used; all interactive controls use standard pointer or keyboard events (WCAG 2.2 §2.5.7)
Social icon links and navigation items include aria-label attributes to provide accessible names beyond visual icon presentation

Understandable

All pages declare <html lang="en"> for correct language identification
Header and footer navigation appear in the same order on every page (WCAG §3.2.3)
Interactive controls with the same function are named consistently across pages (WCAG §3.2.4)
The contact form identifies required fields and displays error messages in text when validation fails (WCAG §3.3.1)
Contact details (email and phone number) appear in the footer on every page in a consistent position (WCAG 2.2 §3.2.6)
No multi-step form process requires a user to re-enter information they have already provided in the same session (WCAG 2.2 §3.3.7)
The site has no user authentication; no login, password, or cognitive-test step exists (WCAG 2.2 §3.3.8 not applicable)
User preferences set through the accessibility toolbar (font size, colour mode) persist across pages using localStorage

Robust

WAI-ARIA roles, states, and properties are applied throughout: aria-label, aria-expanded, aria-controls, aria-hidden, aria-labelledby, and role="dialog" on the mobile navigation overlay
HTML is written to valid, semantic standards; landmark elements are used in preference to generic <div> containers where possible
Compatibility is targeted at current versions of Chrome, Firefox, Safari, and Edge with commonly used assistive technology combinations (NVDA + Chrome, JAWS + Chrome, VoiceOver + Safari on macOS and iOS)

Known Limitations

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

Newsletter sign-up inputs — placeholder-only labelling

Email sign-up fields on the Activities, Events, Accommodation, Blog, and Visitor Guide pages use only placeholder text to describe the input purpose. Placeholder text disappears as soon as the user begins typing and is not consistently announced as a label by all screen readers. A visible or programmatically associated <label> element, or an aria-label attribute, is required.

Impact: Screen reader users may not receive the field description once typing begins.

WCAG 2.2 §1.3.1 Info and Relationships (A) | §3.3.2 Labels or Instructions (A) | §4.1.2 Name, Role, Value (A)

Colour contrast — not formally tool-verified

Visual review of the colour palette suggests the primary text colour (#2a2a2a on #f5f2ee background) and muted text (#5c5c5c) meet the 4.5:1 minimum. The teal accent colour (#3c7a6c) used for links and borders is estimated to meet 3:1 for large text. However, a formal audit using an automated contrast checker (such as WCAG Contrast Analyser or axe) has not been completed across all colour pairings on all pages.

Impact: Some colour combinations — particularly small link text and muted body copy — may not formally meet 4.5:1 without verified measurement.

WCAG 2.2 §1.4.3 Contrast Minimum (AA) | §1.4.11 Non-text Contrast (AA)

Multiple ways to find a page — no site search or sitemap

WCAG requires more than one way to locate any page within the site. Currently, the primary navigation menu and footer links are the only discovery mechanisms. No site search function or dedicated sitemap page is provided.

Impact: Users who cannot use or find the navigation menu have limited alternative routes to reach specific pages.

WCAG 2.2 §2.4.5 Multiple Ways (AA)

Touch target size — not fully verified

WCAG 2.2 requires interactive targets to be at least 24×24 CSS pixels, or have sufficient offset spacing from adjacent targets. Social media icon links in the footer and some smaller navigation items have not been formally measured against this criterion.

Impact: Users with motor impairments or those using touchscreens may find some small targets difficult to activate accurately.

WCAG 2.2 §2.5.8 Target Size Minimum (AA)

Form status messages — ARIA live region not confirmed

The contact form displays a success or error message after submission. It has not been confirmed that these messages are exposed as aria-live regions or via an equivalent ARIA role so that screen reader users receive the announcement without needing to move focus to the message area manually.

Impact: Screen reader users may not be automatically informed of whether their form submission succeeded or failed.

WCAG 2.2 §4.1.3 Status Messages (AA)

Google Tag Manager noscript iframes — missing title attribute

All pages include a hidden Google Tag Manager <noscript> iframe with zero dimensions and display:none styling. These iframes currently lack a title attribute on most pages. A title="Google Tag Manager" attribute has already been added to this accessibility statement page and is being rolled out across the full site.

Impact: Negligible — elements are invisible — but technically a non-conformance.

WCAG 2.2 §4.1.2 Name, Role, Value (A)

If you encounter an accessibility barrier not listed above, please report it. We treat all accessibility reports as priority issues and aim to respond within five working days.

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:

Disabled interface elements

Components that are disabled — such as a greyed-out submit button when a form is incomplete — are exempt from contrast requirements. Their reduced contrast is intentional, signalling to users that the component is not yet interactive. No contrast minimum applies to inactive or disabled state styling.

Decorative text and purely decorative elements

Text that is purely decorative and conveys no information, as well as text hidden from view or not visible to any user, is exempt. On this site, background overlay text used purely for visual texture is treated as decorative and is not relied upon to convey any meaning.

Logotypes

Text that forms part of a logo or brand name is exempt from the contrast requirement. The IVLAND logo, which includes the brand wordmark as an image, is considered a logotype under WCAG 2.2 and is therefore not subject to the 4.5:1 text contrast minimum.

Feedback and Contact

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

- Website: www.iv.land
- Email: info@iv.land
- Phone: 0121 663 0006

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 IVLAND 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

IVLAND 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 IVLAND 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.

Accessibility Statement