Accessibility
Accessibility
Statement
Inclusion is my profession, so this site should hold itself to the standard I ask of others. This statement sets out where it stands, honestly — what works, what doesn't yet, and how to tell me if something gets in your way.
Our commitment
hughokeeffe.com is built to be usable by as many people as possible, regardless of how they browse — including those using screen readers, keyboard-only navigation, screen magnification, or browser settings that reduce motion or increase text size. Accessibility is treated as a baseline requirement of the design, not an afterthought.
Conformance status
This site aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. To the best of my knowledge it currently meets that target, based on a self-review rather than a formal third-party audit. Where any element falls short, I treat it as a defect to be fixed, not a limitation to be documented and left alone.
Measures taken
Specific steps that have been built into the site:
- A "skip to main content" link so keyboard and screen-reader users can bypass the navigation.
- Semantic HTML structure with clear landmarks (navigation, main, footer) and a single, logical heading order.
- Clearly visible keyboard focus indicators on every interactive element.
- Text and interface colours that meet WCAG AA contrast ratios against their backgrounds.
- Full support for reduced-motion preferences — all animation and the scrolling hero effect switch off automatically when a visitor has asked their system to minimise motion.
- Descriptive text alternatives for meaningful images, with purely decorative elements hidden from assistive technology.
- Descriptive link names, including a spoken cue where a link opens in a new tab.
- A responsive layout that reflows cleanly down to a 320px viewport and supports full-page browser zoom to 400% without loss of content.
- The page language is declared so screen readers use the correct pronunciation.
- Form fields have visible, permanently associated labels, with required fields named in words rather than signalled by an asterisk alone.
- Moving content is limited to a single short glide that plays once, triggered when it comes into view, and never repeats — so there is no continuously moving text to distract from or obscure the page.
- The booking calendar is click to load. No third-party code, and no third-party cookies, are loaded until you choose to open it.
- No analytics, no tracking, no advertising scripts, and no accessibility overlay. This site sets no cookies of its own at all.
How this site was built and tested
I take the view that an accessibility statement should describe a method, not just assert a result. So here is the method, including its limits.
The site is hand-written HTML with a utility CSS build. There is no page builder, no template marketplace theme and no accessibility overlay widget — overlays tend to paper over the underlying markup rather than fix it, and they frequently make things worse for screen reader users. Everything here is fixed at source.
It has been reviewed against WCAG 2.2 AA at the code level, working through the success criteria rather than relying on an automated scanner. Automated tools catch a useful minority of issues and miss most of the ones that matter, so they are treated as a first pass, not a verdict. Alongside that review:
- Every text and interface colour pair has been checked by calculating its contrast ratio numerically, rather than judging it by eye.
- The site has been walked through by keyboard alone, checking that focus order follows reading order, that focus is always visible, and that nothing traps focus — including the horizontally scrolling section rail on mobile.
- Heading structure has been checked in sequence for a single H1 and no skipped levels.
- Layout has been checked for reflow at narrow widths and under full-page browser zoom, so content does not require scrolling in two directions. Text-only enlargement has been measured separately and is recorded under known limitations below.
- Motion behaviour has been checked with reduced-motion preferences both on and off, on every page.
- Automated structural checks are run across every page of the site — heading sequence, landmark regions, image alternatives, accessible names on all links and buttons, duplicate IDs, ARIA references that resolve to real elements, label associations on every form field, and absence of positive tab indexes.
Known limitations
A few things are honestly worth flagging, because a statement that claims perfection is not worth reading.
- This is a self-assessment, not an independent audit. No third party has verified these claims. Self-review by someone who knows the criteria is considerably better than nothing, and it is not the same thing as an external audit.
- My writing is published on Substack, a third-party platform whose accessibility I do not control. If you have difficulty there, the Substack help channels are the most direct route, and I would still like to hear about it.
- The opening screen uses a subtle parallax effect. It is disabled automatically for anyone with reduced-motion settings enabled. If you experience discomfort and aren't sure how to turn that setting on, contact me and I'll help.
- The contact form relies on the browser's own validation messages for missing or malformed entries. These are announced by screen readers, but they are less clearly worded than a custom error summary would be. Email is always an equivalent route, and no enquiry is treated as lesser for arriving that way.
- The booking calendar is provided by Calendly, and I do not control what is inside it. It is deliberately click-to-load, so it never loads unless you ask for it, and I have given the frame a descriptive name. Everything inside that frame is Calendly's markup. If you have difficulty booking, email me and I will arrange a time directly — that route will always exist alongside it.
- Text-only enlargement at 200% is not yet fully clean. Most browsers enlarge whole pages, and at 400% full-page zoom this site reflows without sideways scrolling. But if you enlarge text alone — Firefox offers this, as do some operating system settings — the largest display headings on the home page and on this page push past the screen edge at 200%, which introduces a small amount of sideways scrolling. Everything remains readable and every control still works. The fix is fluid heading sizes, and it is on the list rather than filed away.
- The 404 page has no skip link. Its navigation contains a single link, so there is no block of repeated content to bypass. This is a deliberate decision rather than an oversight.
Feedback
If you encounter any barrier on this site, or need information here in a different format, I want to know — and I'll treat it as a priority. Email me at hugh@hughokeeffe.com with a brief description of the problem and the page or feature involved, and I'll respond and aim to put it right.
Technical information
This site relies on HTML, CSS, and a small amount of JavaScript. Where JavaScript enhances the experience — the hero animation, the single ticker glide, the click-to-load booking calendar — the content remains fully readable and navigable without it. With JavaScript disabled, the booking calendar is simply a link.
The only third-party code that can ever run on this site is Calendly's booking calendar, and only after you press the button that loads it. There is no analytics, no tag manager, no advertising, no embedded video, and no accessibility overlay. Fonts are served from this domain rather than a font network.