Skip to main content
All Access Executive Services
Request Access

Legal

Accessibility Statement

AAES's WCAG 2.2 AA conformance target, known limitations, and how to reach us about an accessibility barrier.

DraftDRAFT — pending legal review (docs/06 §11)

This page is engineering-authored draft structure and draft language, prepared to docs/06 (Compliance & Legal) — it is not final legal copy. It has not been drafted, reviewed, or approved by Florida counsel, and nothing on it is legal advice or AAES's adopted policy. Every item marked TBD names an open question — see docs/00 §12 and docs/06 — that must be resolved and counsel-approved before this page can ship (docs/06 §11, review gate).

Last updated:

Our Commitment

AAES wants this website to be usable by everyone, including people who use assistive technology such as a screen reader, switch device, or voice-control software, and people who navigate by keyboard alone. Accessibility is treated as an engineering requirement built into the design system and every page template, not an afterthought (see docs/03 §4 and docs/issues/003) — and as a compliance requirement given active ADA Title III web-accessibility litigation, including in South Florida (see Regulatory Disclosures and docs/06 §9).

Conformance Target

Our target is WCAG 2.2 Level AA (Web Content Accessibility Guidelines, published by the W3C). The component library this site is built from (docs/issues/003) is designed to that standard from the start — real heading structure, keyboard-operable navigation and menus, visible focus states, labelled form fields, colour never used as the only carrier of meaning, and text contrast checked against every real background it appears on.

Current status: an engineering-led audit against WCAG 2.2 Level AA has been completed (tracked as docs/issues/021) across every page template and the interactive components they're built from — navigation menu, mobile menu, forms, FAQ accordion, testimonial carousel, and cookie-consent banner. It combined three things: an automated scan (axe-core) run against the real built site in a browser on every route, plus every open/expanded state those routes can reach; a second, complementary automated pass built into the component/page test suite itself, run in every pull request; and a manual pass — full keyboard-only navigation, visible focus order, 320px and 200%/400%-zoom reflow, heading and landmark structure, and contrast verification of every colour token pair actually used in the design system, extending the check introduced in docs/issues/002. This is a conformance claim grounded in that testing, not a legal certification — see Known Limitations below for what the audit does not yet cover, and the notice at the top of this page for its own review status.

Genuine issues turned up by the audit were fixed, not just logged:

  • Two real colour-contrast failures against WCAG AA — the site's accent colour, used as text (small section labels, and a few hover states) on the site's light-toned page backgrounds, and the same colour used for the visible keyboard-focus ring there — both fell short of the required contrast. Both are fixed sitewide by introducing a slightly darker version of the accent colour for exactly this situation, so every place it's used automatically meets contrast whether the surrounding section is dark or light.
  • Two real keyboard/reflow issues, found only by testing an actual 320px-wide layout (a phone in portrait) rather than a design-tool mockup: the site's mobile navigation button could be pushed entirely off the edge of the screen, with no way to scroll to reach it; and a text link that jumps to a section further down a page could land that section's heading hidden behind the sticky header instead of visible. Both are fixed.

Known Limitations

In the interest of an honest gap over a false assurance, this audit's coverage has limits:

  • Screen reader testing. The audit above is automated-tool and code-level verification (semantic HTML, ARIA roles/states, focus management, keyboard reachability) — it is not a substitute for a human listening to this site with a real screen reader. Live testing with VoiceOver (macOS/iOS Safari) and NVDA (Windows/Firefox), called for in docs/issues/021's scope, has not yet been performed in the environment this audit ran in. This is the single largest gap between this audit and full manual coverage, and it is the next piece of work, not a closed item.
  • Windows forced-colours (high-contrast) mode has not been tested.
  • A minor layout tightness exists in the desktop header at a narrow band of window widths around 1024px (roughly tablet-landscape/small-laptop sizes) — content can be a little cramped there. This is separate from, and does not affect, the 320px mobile layout above, which is fully fixed and tested; it's tracked as a follow-up, not a WCAG conformance blocker.
  • Third-party and embedded content — anything rendered by a service AAES doesn't control — and the content-management admin tool used to edit this site (reachable only by AAES staff, not part of the public site) are outside this statement's scope, consistent with docs/06 §9.

Technical Approach

Things this site does by design, verified by the audit above:

  • One <h1> per page, with no heading-level skips, and consistent landmark structure (header/nav/main/footer) on every page.
  • Every interactive control (navigation, mega-menu, mobile menu, forms, the cookie-consent banner, accordions, the testimonial carousel) is operable by keyboard alone, with a visible focus indicator that meets contrast requirements on every page background.
  • Images carry meaningful alt text, or alt="" when purely decorative.
  • Motion respects a visitor's prefers-reduced-motion setting, including the testimonial carousel's auto-advance and any hero video.
  • Colour is never the only way a status, error, or state is communicated, and every text/background colour pairing used across the site meets WCAG AA contrast.
  • Interactive targets meet the WCAG 2.2 24×24px minimum size everywhere, and 44×44px for primary mobile actions.
  • The multi-step membership application never re-asks for information already entered, including when a visitor navigates back a step.

Feedback & Contact

If you hit an accessibility barrier anywhere on this site, please tell us — through the contact page, or by phone using the number in the site footer; both are monitored, with a one-business-day response commitment. A dedicated, named accessibility-specific contact channel (e.g. its own inbox with a committed response time) has not yet been assigned. Publishing an unmonitored address would be worse than publishing none (docs/issues/021 technical notes), so this section will name a specific, dedicated channel once one is confirmed, rather than a generic one now — use the general contact channels above in the meantime; they reach the same team.

This Statement

This statement describes AAES's accessibility target and the completed and outstanding parts of the docs/issues/021 audit as of the "Last updated" date above. It will be revised as the remaining items under Known Limitations are completed.