Accessibility

1. Conformance status

This website aims to conform to WCAG 2.2 Level AA. It is currently assessed as substantially conformant: the great majority of requirements are met, with the exceptions listed in section 3. The site has been reviewed manually — keyboard-only navigation, focus order, screen-reader semantics, contrast measurement, zoom, and motion behaviour — rather than relying on an automated score alone.

The site is deliberately built so that every word of content is present in the HTML and readable with JavaScript disabled, animations are decorative only, and no critical function depends on hover, drag or precise pointing.

2. What is in place

• Semantic structure — one h1 per page, a logical heading outline, landmark regions (header, nav, main, footer) and labelled navigation.
• Keyboard access — everything reachable by tab, in a sensible order; a visible focus ring on every interactive element; a “Skip to content” link as the first tab stop.
• Screen readers — descriptive link text, aria-labels on icon-only controls, alternative text on meaningful images and empty alt on decorative ones, plus a text alternative for the animated hero heading.
• Motion — prefers-reduced-motion disables the intro sequence, parallax, marquee and reveal animations; nothing moves without user action on a touch device.
• Colour and contrast — a light and a dark theme, both meeting the 4.5:1 contrast requirement for body text and 3:1 for large text and interface borders; colour is never the only signal for meaning.
• Resize and zoom — layout reflows from 320 px upward and stays usable at 200% zoom; text sizes use relative units; no horizontal scrolling on a phone.
• Touch targets — interactive controls sized for comfortable tapping with adequate spacing.
• No traps — no keyboard traps, no autoplaying audio, no time-limited content, no flashing or strobing animation.

3. Known limitations

• Animated hero canvas — the decorative particle canvas is hidden from assistive technology (aria-hidden) and its information is repeated in text, so it does not carry meaning for anyone. It is not rendered at all for reduced-motion users.
• Custom cursor on desktop — the decorative cursor ring is only enabled for fine-pointer devices and is never required to operate anything.
• Third-party destinations — links to WhatsApp, LinkedIn, GitHub and X leave this site. Their accessibility is outside my control, and I would rather hear about a barrier there than have you meet it silently.
• PDF content — should a document be published in future, it will be provided with an accessible HTML alternative on request.

If you find a barrier that is not on this list, treat it as a defect: report it and it will be fixed.

4. How to report a problem

Email info@wilsondevops.com or message WhatsApp. Helpful details, if you have them: the page, what you were trying to do, your browser and assistive technology. You do not need to be technical — a plain description is enough.

• I acknowledge within 2 business days.
• Blocking issues are prioritised and fixed as quickly as possible, usually within 10 business days.
• If a barrier stops you getting information you need, tell me and I will provide the content in another format — email, plain text, or a call — at no cost.

5. Accessibility as part of client work

The same standard is applied to the projects I build for clients: semantic markup, keyboard operability, labelled controls, contrast-checked palettes, reduced-motion support and tested focus states. Where a project includes an accessibility audit against WCAG 2.2, the deliverables are a findings report, prioritised fixes by severity, and a re-test to confirm each one is resolved. Accessibility is part of delivery, not a paid extra bolted on at the end.