Accessibility

Our commitment

We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA throughout this website, and to go further than that where it makes the site genuinely easier to use.

Our working rule during the build was simple: accessibility is never traded away for visual effect. Where the two conflicted, the design changed.

What we have done

Text and contrast

• Body text is set at a comfortable size that scales with your browser settings, with generous line spacing and line lengths kept short enough to read without losing your place
• Every page was checked with an automated contrast test, and colour values were also calculated by hand against the WCAG AA thresholds. Where a combination failed, we changed it: the footer legal text and the definition lists on the dark green bands were both fixed this way, having rendered at roughly 1.8:1 and 1.3:1 against a 4.5:1 requirement
• Text resizes and the layout reflows. We checked every page at widths from 320px to 1920px, and at the reflow width equivalent to 200% zoom, with no horizontal scrolling and no content cut off
• We have avoided using colour as the only way of conveying information. This is a design rule we applied rather than something an automated test can confirm, so if you find somewhere it fails, please tell us

Keyboard and focus

• We have not removed default focus styling anywhere, and every control we tabbed through carried either an outline or a focus ring. On the homepage we stepped through all 70 focusable elements one by one and found no control that was unreachable, invisible while focused, or trapped
• Scrollable areas — the comparison tables in the guides, which scroll sideways on a narrow screen — are reachable with the keyboard, not just by dragging
• A "skip to content" link is the first thing in the tab order on every page
• Navigation menus can be opened with Enter or Space and closed with Escape, and they report their open or closed state to assistive technology

Structure and semantics

• One main heading per page, with headings nested in a logical order so a screen reader user can navigate by structure
• Landmarks for header, navigation, main content and footer
• Native HTML elements used wherever possible — real buttons, real links, native expandable sections — rather than scripted imitations
• Link text that makes sense out of context, so a list of links is useful on its own
• Breadcrumbs on inner pages, with the current page marked

Forms

• Every field has a visible, permanently present label — no placeholder-only labels
• Hints are associated with their fields, so they are announced rather than merely visible
• Required fields are marked in the label text as well as programmatically
• Errors are reported by the browser in text, next to the field concerned, and never by colour alone
• Fields use appropriate input types and autocomplete hints so browsers and password managers can fill them in
• Checkbox and radio groups are grouped with a description, so the question is announced along with the options

Motion and images

• Animation is restrained and decorative only. Nothing moves automatically, nothing flashes, and nothing scrolls on its own
• All motion is disabled if your device is set to reduce motion, and content that fades in is shown immediately instead. We tested this with the reduce-motion preference on and confirmed every section renders at full opacity with no transition
• Decorative graphics are hidden from assistive technology so they are not read out as meaningless content
• Content is readable with JavaScript unavailable. Sections that fade in as you scroll are only hidden when scripting is available to reveal them, so with JavaScript off the page simply renders normally

Language and mobile

• We have worked hard on plain English. Sector jargon is explained where it appears, because "PHB" is not an explanation
• The site is built mobile-first, with tap targets sized for real fingers and a navigation menu designed for one-handed use
• The site works in portrait and landscape, and at high zoom levels

Known limitations

We would rather list these than claim full conformance.

• No screen reader testing has been carried out. The site is built from semantic HTML and has been tested by keyboard and with automated checks, but nobody has yet sat down with JAWS, NVDA or VoiceOver and worked through it. Until that happens we cannot tell you how it sounds, only how it is marked up.
• Automated testing proves less than it appears to. Our automated checks currently report no errors on any page. That is worth having, but tools of this kind detect only a minority of accessibility barriers — they cannot judge whether a heading is meaningful, whether link text makes sense, or whether a page is actually usable. We are not treating a clean result as evidence of conformance.
• No user testing with disabled people yet. This is the gap we are least comfortable with, because it is the testing that finds what automated tools miss. It is on our list.
• Form errors rely on the browser. Our forms use native browser validation, which is reliable and announced but less precisely worded than custom error messaging would be.
• The CV upload is a standard file input. It is keyboard accessible and labelled, but if uploading a file is difficult for you, email your CV instead and it will be treated identically.
• Keyboard testing was thorough on some pages, not all. We stepped through the homepage, the navigation menus and the forms control by control. The remaining pages share the same components, so we expect them to behave identically, but we have not walked through every one.
• Long guides are long. Each has an "on this page" navigation, but some of our resource pages are substantial documents. If you would like a summary of one, ask and we will write you one.

We are not claiming a formal conformance level we have not independently verified. What we are claiming is that the guidelines were applied deliberately throughout, and that we will fix what we get wrong.

How the site should behave

So you can tell whether something is broken:

• Pressing Tab from the top of any page should reveal a "Skip to content" link first
• Navigation sections open on Enter or Space, and close on Escape, returning focus sensibly
• Zooming to 200% should not cut off content or require horizontal scrolling to read text
• With reduced motion enabled, nothing should fade, slide or animate
• With images blocked, no information should be lost
• With JavaScript disabled, every page should still be readable and every form usable

If any of that is not true for you, it is a bug. Please tell us.

Other ways to reach us

You never have to use a form on this website to contact Oakline.

• Telephone: +44 7572 245085 — often the fastest route, and the one we would suggest if forms are difficult for you
• Email: info@oaklinehealthcare.co.uk — write as much or as little as you like; there is no required format
• Someone else on your behalf: a relative, friend, advocate or professional can contact us for you. We will ask for your agreement before discussing your situation in detail

If you need information from this site in another format — large print, plain text or a summary — ask us and we will provide it. If you need us to communicate in a particular way, tell us and we will work with it.

Telling us about a problem

If you find something on this site that is difficult or impossible to use, we want to know. Email info@oaklinehealthcare.co.uk or call +44 7572 245085.

It helps if you can tell us the page, what you were trying to do, and what happened — plus your browser and any assistive technology you use, if you know. But a message that simply says "I could not use your contact form" is enough to start with.

We will acknowledge it, tell you what we can do, and fix what we can. If something cannot be fixed quickly, we will say so and offer you another way to get what you needed.

How we tested this

So you can judge how much weight to give the claims above, here is precisely what was done, and when. All of it was carried out on 23 September 2026 against the current version of the site.

• Automated checks. axe-core run against all 36 pages in a real browser engine, at the WCAG 2.0 A and AA, 2.1 A and AA, and 2.2 AA rule sets. Result: no violations. Two genuine contrast failures found by an earlier run were fixed rather than excused.
• Keyboard. All 70 focusable elements on the homepage stepped through in order, checking reachability and a visible focus indicator at each stop. Navigation dropdowns opened with Enter, closed with Escape, and returned focus to the control that opened them. The mobile menu was opened, closed with Escape and confirmed to restore page scrolling.
• Links. Every internal link, breadcrumb, call to action and in-page anchor across all 36 pages was followed and confirmed to resolve.
• Layout. Every page rendered at 320, 390, 768, 1024, 1280 and 1920 pixels wide, and at the narrow viewport equivalent to 200% zoom, checking for horizontal scrolling and clipped content. Three guides and one other page failed this and were fixed.
• Reduced motion and no JavaScript. The site loaded with the reduce-motion preference enabled, and again with JavaScript disabled entirely, checking that no content stayed hidden in either case.
• Contrast by calculation. Foreground and background values taken from the rendered page and checked against the 4.5:1 threshold arithmetically, not by eye.

What we have not done: tested with a screen reader, tested with speech recognition or switch access, or asked disabled people to use the site and tell us what is wrong with it. Those are the tests that find what the others miss, and until they happen this statement describes a site that has been built and checked carefully, not one that has been independently verified as conformant.

This statement describes the site as at the date above, and we will update it as the site changes and as further testing is completed.