Accessibility statement

Conformance target

This site targets Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, and names specific success criteria when describing a fix rather than saying "accessibility issue" in general.

The target covers every page here: the main page, this statement, the form confirmation page, and the not-found page. All four share one stylesheet, so a contrast or focus-visibility fix cannot land on one page and silently miss the others.

This is a small site maintained by one person with no continuous integration gate on accessibility. Conformance is checked by review, not enforced automatically on every change. That is a real limitation and it is stated here rather than implied away.

What has actually been tested

This site is new. The list below is deliberately short, and will stay honest as it grows.

• Built on reviewed patterns. The landmark structure, skip link, focus-visible styling, contrast tokens, and new-tab link announcements are carried over from a sibling site (opens in a new tab) where those specific patterns were manually audited, scanned with WAVE and axe-core, and operated with VoiceOver in Safari. Inheriting an audited pattern is a reasonable starting point; it is not the same as testing this site.
• Source-level review. Heading order, one h1 per page, landmark placement, list semantics where CSS removes list markers, decorative rules marked aria-hidden, and link purpose were checked by reading the markup.
• Form semantics. The interest form uses a real <fieldset> and <legend> for the checkbox group, an explicit <label> for every control, required fields marked in visible text as well as with the required attribute, and help text associated by aria-describedby rather than left floating.

Known issues and untested areas

• No screen-reader pass on this site yet. VoiceOver, NVDA, JAWS, and TalkBack have not been run against these pages. The form in particular — error handling, required-field announcement, and submission confirmation — has not been operated with a screen reader.
• No automated scan on the live URL yet. WAVE and axe-core have not been run against these pages as deployed.
• Form validation messages are the browser's defaults. Native constraint validation is used rather than custom in-page error summaries. Native messages are announced by most screen readers but are not always well placed, and there is no error summary at the top of the form. This is a known gap, not a design position.
• Fonts load from a third party. Typography comes from Google Fonts. If that request is blocked, the page falls back to system fonts; layout and contrast were checked to survive that, but it has not been tested with fonts blocked on every page.

These will be worked through and this list updated with dates. Until then it stays here in full.

Report a barrier

If something here doesn't work for you, we want to know, even if the report is imperfect. Email ecogetaway@gmail.com (opens your email application). Useful detail, if you have it: which page, what you were trying to do, what happened instead, and what browser or assistive technology you were using. All of that is optional. A report that just says "this didn't work" is still worth sending.

Language

This statement uses direct, person-centered language and follows individual preference where it is known, whether person-first or identity-first. It avoids euphemisms such as "differently abled" or "people of all abilities."