Legal

Accessibility

Use the skip link and headings to navigate this reference, and the associated labels to identify calculator and contact inputs. Tables include headers and captions. If a page or form presents an accessibility barrier, send the page address and what prevented the task through contact. Website access and a venue’s physical access require separate checks.

Access to the planning information

Calculator pages include a fixed worked example alongside the interactive form. The example remains readable without the calculator script; interactive results need scripting. Native question disclosures, where present, may be announced differently by different browsers and assistive technology.

We aim for WCAG 2.2 AA. This is an accessibility objective, not a claim of independent certification across every browser or assistive technology. Report a barrier through contact, including the affected task and browser if useful, without sensitive guest or medical information.

Check the venue route separately

The venue access guide covers the route from parking to ceremony, dinner and toilets, including an indoor weather alternative. An accessible website or hotel-room label does not establish that every event route meets a guest’s needs.

Contact verification uses Cloudflare Turnstile when configured. The widget is a separate interaction; Cloudflare’s Turnstile documentation describes the service and its accessibility support.

Accessibility here aims to meet WCAG 2.2 Level AA. In practice that means a few concrete things you can check. Every page is ordinary semantic HTML with one heading structure and a skip link.

Every color pairing was chosen to clear the contrast requirement in both directions. Every form control has a real label attached to it. Every data table has proper header cells, so a screen reader can announce a value with the row and column it belongs to.

Nothing on the site requires a mouse. The calculators are progressive enhancement: each one shows a complete worked example in plain HTML before any script runs, so the answer is available whether or not the script loads.

What has been done

Semantic HTML throughout, with one h1 per page and headings in order.

A skip link to the main content as the first focusable element on every page.

Visible focus outlines, never removed

Text contrast checked against WCAG 2.2 AA for every color pair used.

Every form input has an associated label
Errors are announced through a live region instead of color alone.

Data tables use th with a scope, plus a caption, and reflow to labelled rows on a narrow screen instead of scrolling horizontally in an unlabelled grid.

Every diagram is inline SVG with a title and a text alternative describing what it shows.

The site works at 320 pixels wide and at 200% zoom without loss of content.

No autoplaying media, no motion, no carousels and no timed content

Known limitations

The question-and-answer blocks use native details and summary elements, which are keyboard accessible and screen-reader accessible but announce differently across browsers. If you find this a barrier, tell us.

A note on the accessibility of the venues themselves

The accessibility of this website is a separate matter from the accessibility of the venues it describes, and the second is much worse served. Few Vermont wedding venues publish anything about physical access. We record what they do publish and we say plainly where they publish nothing: see accessibility at Vermont venues for what to ask.

Reporting a barrier

If any part of this site is difficult or impossible for you to use, please tell us through the contact form and describe what happened. We treat an accessibility barrier as a correction and aim to respond within two business days.