Youth-led support in Rochdale

Youth-led support in Rochdale
Join a session

Empower young people and strengthen the wider community through practical guidance, safe spaces, and youth-led support.

Accessibility statement

How accessibility is handled on the live EncouragingYou website.

This statement covers the live public site, explains what has been checked so far, and shows the clearest route to ask for help or report a barrier.

Report an accessibility problem Read the Cookie Notice

Current statement scope

This is a launch-ready accessibility statement for the live site build. It does not claim a full independent audit or a formal declaration of complete compliance.

What the site aims for

The live site is built with WCAG 2.2 AA as the working standard for the public launch build.

  • Readable contrast and visible focus states
  • Keyboard-friendly navigation and disclosure patterns
  • Clear form labels, helper text, and error states
  • Reduced-motion-safe behaviour where motion is used

What has been checked so far

Accessibility has been reviewed through the current build, the shared component system, and the automated checks already wired into the repo.

  • Keyboard reachability for skip links and FAQ disclosures
  • Reduced-motion handling on the live shell
  • Structured form validation, focus recovery, and no-JS confirmation flow
  • Browser and responsive checks through Astro and Playwright

What is still limited

The site is honest about the difference between current checks and a full audit.

  • No independent accessibility audit is published yet
  • External platforms such as Instagram, email clients, and calendar apps are outside the main site's direct control
  • A full assistive-technology compatibility matrix is not published at launch

What the site already does

Accessibility support is built into the current shell, form system, and content patterns.

The site does not rely on a single accessibility widget or one isolated route. The working expectation is that the core public journeys should be understandable, keyboard reachable, and low-friction by default.

Structure and navigation

The main shell includes skip links, breadcrumb support, clear heading hierarchy, and a mobile navigation pattern that can be opened, closed, and escaped from the keyboard.

Forms and feedback routes

Live forms use labels above fields, helper text, visible validation, focused error recovery, and a no-JavaScript confirmation fallback instead of depending on placeholder-only labelling or client-side scripting alone.

Motion, media, and low-JS choices

Reduced-motion preferences are respected, decorative imagery is kept separate from trust-critical claims, and the launch build avoids heavy third-party embeds such as an auto-loaded interactive map on the contact route.

Launch evidence

The current statement is based on repo evidence, not a claim of perfection.

The live statement distinguishes between what has been tested in the current repo and what still needs deeper review or future auditing.

Manual launch review

The current build has been reviewed for keyboard reachability, visible focus treatment, reduced-motion behaviour, responsive layouts, and form handling across the main public routes.

Automated checks in the repo

The site runs shared unit checks, Astro validation, and Playwright browser checks as part of the current quality gate. Those checks support the statement, but they are not a substitute for an independent audit.

Review date

This statement was reviewed against the live launch build on 23 April 2026.

Current accessibility posture

Working target: WCAG 2.2 AA. Assessment approach: self-evaluation.

No independent audit published yet

Cookie choices

This site does not show a cookie banner at launch. The Cookie Notice explains the live first-party aggregate analytics model, the objection control on that route, and the storage that stays absent.

Known limitations

Some boundaries are already known, and they are shown here plainly.

Known limitations are listed to reduce frustration. When there is a workaround or a better route, it should be visible alongside the limitation rather than hidden in support replies.

External platforms are outside the main website's direct control

Instagram, email applications opened from mailto links, and calendar applications opened from .ics files are not part of the core site runtime.

What this means
Accessibility on those platforms depends on the provider and the app someone uses.
Alternative or next step
If an external destination blocks you, use the accessibility feedback form or the published email route and explain what you were trying to do.

Calendar downloads depend on the app that opens them

The session routes provide .ics files as a convenience, but the experience after download is controlled by the calendar app or device, not by the website itself.

What this means
Import behaviour, reminders, and display may vary between devices and calendar tools.
Alternative or next step
Use the session page itself as the source of truth for the next date and contact the team if you need the timing confirmed in another format.

A full assistive-technology compatibility matrix is not published yet

The launch build includes manual and automated checks, but it does not yet publish a named matrix for every browser and assistive technology combination.

What this means
Some combinations may work well without being individually documented in public yet.
Alternative or next step
Report the exact combination that caused difficulty so the team can reproduce it and respond more precisely.

External tools and destinations

The statement separates the main site from the services it links out to.

This helps keep the statement truthful. The main site can describe and limit its own behaviour, but it should not overclaim control over platforms or applications it does not run.

Instagram and other social destinations

Social links leave the site and move into a third-party platform with its own accessibility, privacy, and account settings.

Email and calendar apps

Mailto links and calendar files are provided as practical next-step helpers, but the app that opens afterwards is outside the site's direct control.

Maps and directions

The launch contact route does not load an interactive map by default. If a public directions link is added later, it will need its own external-service note and review.

Feedback and help

Tell us if something is difficult to use or if you need another format.

The accessibility route should help people reach a practical response, not just acknowledge a principle.

Need help using the site?

Use the dedicated accessibility feedback form if something on the site is difficult to use or if you need information in another format.

What helps most in a report

Use the accessibility feedback form or the published email route and we will reply as soon as we can.

  • Tell us which page or action caused the problem
  • Tell us what you were trying to do
  • Tell us what device, browser, or assistive technology you were using if you know it
  • Tell us if you need the information in another format

Need a general support reply instead?

If the issue is mainly about joining a session, getting help, or asking a wider question, the Contact route is still available as the general conversation path.

Go to Contact

Keeping this current

This statement should change when the build changes.

The statement is tied to the live public build, not to future plans or ideal conditions.

Review triggers

  • A new public form, embed, processor, or third-party platform is added
  • A published directions or map link goes live
  • A formal accessibility audit is completed
  • A new known limitation is found on the live site
  • Core route behaviour changes in a way that affects keyboard, motion, forms, or media
  • This site does not show a cookie banner at launch. The Cookie Notice explains the live first-party aggregate analytics model, the objection control on that route, and the storage that stays absent.