Accessibility Statement

Our commitment

Evering is committed to making our wedding-photo galleries usable by everyone, including people with disabilities. We design and build to the Web Content Accessibility Guidelines (WCAG) 2.2 at conformance Level AA. This is the minimum standard set out in the Australian Human Rights Commission's April 2025 Guidelines on Digital Accessibility for organisations meeting their obligations under the Disability Discrimination Act 1992 (Cth). The guidelines also call out mobile accessibility and cognitive disability support — both of which we treat as in-scope, not optional.

Conformance status

Evering targets WCAG 2.2 Level AA and is partially conformant: parts of the product meet the standard, others have known limitations listed below. We have not yet been audited by an independent accessibility specialist — this self-assessment reflects internal automated testing and code review only.

The product is continuously tested against:

• Automated axe-core scans in CI (Playwright e2e covering the guest gallery and dashboard core flows).
• Static analysis at lint time via ESLint with eslint-plugin-jsx-a11y (full recommended rule set). The build fails on any accessibility lint error.
• Manual code review against the WCAG 2.2 AA Success Criteria for every user-facing pull request.

We have not yet completed an end-to-end screen-reader walk-through of every flow with NVDA, JAWS, or VoiceOver. We aim to add that to our release process and to commission an independent audit before the end of 2026.

Features that support access

• Skip to main content link on every page, visible on keyboard focus.
• Semantic landmarks (header, main, nav, footer) on every screen.
• Visible focus rings on all interactive controls; focus order matches reading order.
• Resizable text up to 200% without loss of content or function; we never disable browser pinch-zoom.
• Reduced motion: when the operating system requests reduced motion, all non-essential animations are shortened to near-zero duration.
• Accessible names on every form field, button, and link; icon-only controls carry aria-label annotations.
• Live regions announce upload progress, face-search status, and error states to screen readers.
• Focus management: dialogs trap focus while open and return it to the trigger on close; Escape always closes.
• Colour contrast: body text meets WCAG 1.4.3 AA (≥ 4.5:1); large text and non-text indicators meet 1.4.11 (≥ 3:1).
• Mobile accessibility: touch targets meet the WCAG 2.5.8 AA minimum of 24×24 CSS pixels; viewport reflows at 320 px width without horizontal scrolling (1.4.10); native virtual-keyboard handling preserves the focused input above the keyboard.
• Cognitive support: errors are plain language and suggest a fix; the share-link PIN allows paste (no memorisation requirement, WCAG 3.3.8); no uninterruptible time limits anywhere in the bride or guest flow (2.2.1).

WCAG 2.2 success criteria we test against

This is a non-exhaustive list of the specific criteria our automated and manual tests cover. Each one corresponds to a test in our CI pipeline or a documented engineering rule:

• 1.1.1 Non-text Content (alt text on every image)
• 1.3.1 Info and Relationships (semantic HTML)
• 1.3.5 Identify Input Purpose (autocomplete)
• 1.4.3 Contrast Minimum
• 1.4.4 Resize Text (200% without loss)
• 1.4.10 Reflow (320 CSS px)
• 1.4.11 Non-text Contrast
• 1.4.12 Text Spacing
• 2.1.1 Keyboard (no pointer-only paths)
• 2.1.2 No Keyboard Trap
• 2.2.1 Timing Adjustable (no forced timeouts)
• 2.3.3 Animation from Interactions
• 2.4.1 Bypass Blocks (skip link)
• 2.4.3 Focus Order
• 2.4.6 Headings and Labels
• 2.4.7 Focus Visible
• 2.5.8 Target Size Minimum (WCAG 2.2 AA)
• 3.1.1 Language of Page
• 3.2.1 On Focus (no surprise navigation)
• 3.3.1 Error Identification
• 3.3.2 Labels or Instructions
• 3.3.3 Error Suggestion
• 3.3.7 Redundant Entry (WCAG 2.2 AA)
• 3.3.8 Accessible Authentication (WCAG 2.2 AA)
• 4.1.2 Name, Role, Value
• 4.1.3 Status Messages

Known limitations

The following items do not yet meet WCAG 2.2 AA. We have documented them so that users relying on assistive technology can decide whether the product fits their needs, and so that we can be held to remediation. If any of these blocks your use of the product, please report it (see “Report a barrier” below) — we will help you work around it while we fix it.

• Guest-uploaded photo alt textis auto-generated from the uploader's name (“Photo by Alex”), not a description of the image content. Screen-reader users do not get a meaningful description of individual photographs. WCAG 1.1.1 (Non-text Content). We are evaluating an automatic-captioning model; until then, the gallery context (couple names, event date, uploader) is the available description.
• QR-code logo cropping (dashboard only) is primarily a pointer-drag interaction. Keyboard users can focus the crop area and use Arrow keys to move, Shift+Arrow to resize, and Home/End to jump to corners, but the drag affordance is more discoverable visually. We are working on a more equivalent keyboard UX.
• Video previewsin the lightbox use the browser's native video controls; captions/subtitles are only present when the uploader supplied them. WCAG 1.2.2 (Captions). We do not generate captions for guest-uploaded video.
• Focus-ring colour on some buttons is the brand terracotta against cream-surface, sitting at approximately 3.1:1 — just above the 3:1 WCAG 1.4.11 minimum. Users with low vision who rely on a strong focus indicator may find this insufficient. We are evaluating a stronger ring for the next visual refresh.
• White text overlayson user-supplied cover photos (gallery hero, dashboard event card) depend on the underlying photo's brightness for contrast. On unusually bright covers, captions may fall below WCAG 1.4.3. The scrim gradient mitigates most cases but cannot guarantee 4.5:1 in every photograph.
• No end-to-end screen-reader walkthrough has been performed on the multi-stage face-search flow (selfie capture across three head poses). The flow uses live region announcements for each stage transition, but we have not verified the full sequence with VoiceOver or NVDA. WCAG 4.1.3 (Status Messages).
• Third-party services embedded inside Evering (Lemon Squeezy checkout, Sentry error reporter, Vercel Analytics) are not under our direct control. We choose providers that publish their own accessibility statements, but we cannot guarantee their conformance.

This list is updated as we discover and remediate issues. Last revision: 22 May 2026.

Report a barrier

If you find content or a flow you can't use, please tell us. We treat every report as a defect and prioritise it accordingly. Our commitment:

• Acknowledgement within 2 business days of receiving your report.
• A workaround offered within 5 business days where one exists (we will help you complete the task by another route while we fix the underlying issue).
• WCAG 2.2 Level A or AA failure remediated within 30 days of confirmation, or a clear timeline if remediation will take longer (e.g., dependencies on third-party providers).
• Status updates at least every 14 days until the issue is closed.

Email support@evering.co with the URL, a description of the barrier, and the assistive technology you were using (if any).

Enforcement procedure (Australia)

If we are unable to resolve your concern, you can lodge a complaint with the Australian Human Rights Commission under the Disability Discrimination Act 1992 (Cth).