Accessibility Statement

Last reviewed: [Date of the most recent accessibility review. Set it when you actually test, and re-date it whenever the site changes materially. A statement dated three years ago tells a reader you stopped paying attention.]

Our commitment

This site is built to be usable by as many people as possible, including people who navigate by keyboard, who use a screen reader or magnifier, who need larger text, who are sensitive to motion, or who have difficulty with fine pointer control.

The target standard is the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. That is a target the site is designed and maintained against, not a certification. Where the site falls short, the honest position is to say so and fix it, which is what the sections below are for.

What has been implemented

These are specific measures built into the site, not aspirations:

• Semantic landmarks. Every page uses real header, nav, main and footer regions, so assistive technology can jump between them rather than reading linearly from the top.
• Skip link. The first focusable element on every page is a "Skip to content" link that moves focus past the navigation. It is hidden until focused, then visible.
• Keyboard operation throughout. All navigation, links, form fields and buttons are reachable and operable by keyboard alone. No component requires a mouse.
• Disclosure menus announce their state. The dropdown menus in the main navigation are real button elements carrying aria-expanded, updated as they open and close, so a screen reader announces whether a menu is open. Escape closes any open menu and returns focus.
• Visible focus indicators. A three-pixel high-contrast outline with an offset is drawn around whatever currently has keyboard focus. The browser default is never removed and left unreplaced.
• Reduced motion is respected. If your operating system is set to reduce motion, the site honours prefers-reduced-motion: scroll animation, fade-in transitions and hover movement are switched off rather than merely shortened.
• Nothing depends on JavaScript to be readable. Content that fades in on scroll is fully visible with scripts disabled or blocked, and the FAQ accordions are native HTML details and summary elements, which open, close and announce themselves correctly without any script at all.
• Text scales. Type is set in relative units on a fluid scale with no fixed pixel sizes, so browser zoom and larger default text sizes enlarge the page without clipping or overlapping content.
• Wide content scrolls inside itself. Tables are wrapped in horizontally scrollable containers so the page body never scrolls sideways on a narrow screen.
• Images carry alternative text. Informative images are described; decorative graphics, including the brand mark, are marked aria-hidden with empty alt text so they are not announced as noise.
• Form fields have real labels. Every input is associated with a visible label, and hints are text rather than placeholder-only instructions that disappear on typing.
• Text contrast is measured, not estimated. Body text, headings, links and the smaller secondary text used for captions, breadcrumbs, metadata, table headers and form labels all meet or exceed the 4.5:1 ratio WCAG 2.2 Level AA requires at those sizes, against each background they are actually drawn on. The keyboard focus outline is held above 3:1 against both the light and the dark surfaces it appears on.
• Colour is never the only signal. Required fields, errors and status messages are conveyed in words as well as colour.
• Language is declared. Each page declares lang="en" so screen readers use the right pronunciation rules.

Known limitations

This section previously recorded a colour contrast shortfall: the muted grey used for captions, breadcrumbs, metadata and field labels, and the brass tone used for small uppercase labels, arrow links and button text, both sat below the 4.5:1 ratio required at those sizes. Both tones have been darkened and every surface they are used on has been re-measured, so that shortfall no longer applies. What remains below is material we do not control, and the limits of how this statement was assessed.

Content and components outside our control

[List here, honestly, anything you add later that you do not control. Realistic candidates for this practice: an embedded patient portal or intake questionnaire, a third-party scheduling widget, a video platform, a payment page, and PDF forms. Any of these may not meet WCAG 2.2 AA regardless of how the rest of the site is built. Two things matter: say so here by name, and offer an alternative route for anyone who cannot use them — usually "call the office and we will complete this with you." An unusable intake form with no alternative is the fact pattern that turns an accessibility complaint into a claim of denied access to care.]

[If you keep loading the two web font families from Google's servers rather than self-hosting them, note that a visitor whose network blocks that request will see fallback fonts. Layout is designed to degrade cleanly, but say it rather than let someone wonder whether the page is broken.]

Scope of assessment

This statement is a self-assessment based on manual keyboard testing, screen reader spot checks and review of the site's markup and stylesheet. It is not the result of an independent third-party audit. [If you commission a formal audit or a VPAT, say so here with the evaluator's name and the date, and link the report. If you do not, leave this sentence as written — a self-assessment described accurately is credible; a self-assessment described as an audit is not.]

Testing and maintenance

Accessibility is treated as part of maintaining the site rather than a one-off task. New pages and changes are checked for keyboard operability, heading order, alternative text and contrast before publication.

[State how often you will re-review — annually is a reasonable commitment for a site this size — and then actually diarise it. Do not promise quarterly review you will not perform; an unmet published commitment is evidence, not decoration.]

Reporting a barrier

If any part of this site is difficult or impossible for you to use, please tell us. A description of the page, what you were trying to do, and the browser or assistive technology you were using is enough — you do not need to identify the technical cause.

• [Accessibility contact email on the practice domain. Use an address a person actually reads, not a form-only route — someone who cannot use the contact form needs a way to reach you that does not require using the contact form. That is the entire point of this section.]
• [Accessibility contact phone number, and state whether it accepts relay-service calls. Naming a voice line and a written route covers most needs.]
• [Postal address, if you want to offer a written route.]

We aim to acknowledge reports within [response timeframe — commit to something you can meet in a solo practice. Five business days to acknowledge, with a plan or a fix within thirty, is realistic and defensible. Do not write "immediately" or "within 24 hours" on a page that will still be live during a fortnight you are on service.] and to describe what we can do about the problem, including offering an alternative way to get the information or complete the task while a fix is in progress.

Please do not include health information in an accessibility report. Describe the technical problem only; see the Website Privacy Policy for why.

Formal complaints

[Ask counsel whether to list an external complaint route here — for example the HHS Office for Civil Rights, which handles disability access complaints against healthcare providers as well as the HIPAA complaints listed in your Notice of Privacy Practices. Some practices include it as a good-faith signal; others prefer to keep the first route internal. It is a judgement call, and it should be a deliberate one.]