Accessibility statement

The commitment

I write copy for a living, which means my entire job is making things understandable. A website that some people cannot use is a website that has failed at that job. Accessibility here is treated as part of the work rather than a compliance checkbox added at the end.

This statement covers rivetingcopywriter.com and every page on it. It is written to the W3C’s recommended structure so it can be checked against, not just read.

Conformance status

The Web Content Accessibility Guidelines (WCAG) define requirements at three levels: A, AA and AAA.

This site is substantially conformant with WCAG 2.2 Level AA. “Substantially conformant” means most of the site meets the standard, and the specific areas that fall short are listed openly in the known limitations section rather than quietly omitted.

New Zealand government agencies are required to meet the NZ Web Accessibility Standard, which is based on WCAG. As a private business I am not legally bound by it — I have built to it anyway, because it is the right target.

What has been done

Structure and navigation

• One <h1> per page and a heading order that never skips a level, so screen-reader users can navigate by headings
• Semantic landmarks — header, nav, main, footer, article, aside — on every page
• A “Skip to content” link as the first focusable element, visible as soon as it receives focus
• Breadcrumbs on articles, service pages and policies
• Every page reachable within two clicks of the homepage

Keyboard and focus

• Every interactive element — links, buttons, form fields, the theme toggle, accordions, slider controls, filters — is reachable and operable by keyboard alone
• A visible focus ring on every focusable element, meeting the WCAG 2.2 focus-appearance requirement
• Focus order follows the visual reading order; no positive tabindex values are used
• The mobile menu can be closed with Escape and does not trap focus
• No keyboard shortcuts are bound to single characters, so speech-input users are not caught out

Colour and contrast

• Body text meets or exceeds the 4.5:1 contrast requirement in both light and dark themes; large headings meet 3:1
• Interface components and focus indicators meet the 3:1 non-text contrast requirement
• Colour is never the only way information is conveyed — form errors carry text, category filters carry labels, list markers carry symbols
• A dark theme is available, remembered between visits, and reachable by keyboard

Forms

• Every field has a visible, permanently attached <label>. No placeholder-only labels.
• Required fields are marked in text, not only with an asterisk or colour
• Errors are described in words that say how to fix the problem — “Please write at least 30 characters (5 so far)” rather than “Invalid input”
• Errors are announced to assistive technology via role="alert" and aria-invalid, and focus moves to the first field needing attention
• Correct autocomplete attributes on name and email, so stored details fill in automatically
• Nothing submits or changes context automatically when a field gains or loses focus

Motion and animation

• prefers-reduced-motion is respected site-wide: scroll reveals, parallax, the typing effect, the custom cursor, counters, slider autoplay and page transitions all switch off when your system asks for reduced motion
• No animation flashes more than three times per second
• The moving text band and the testimonial slider both pause on hover and focus, and neither is the only place any information appears

Text and reading

• Text resizes to 200% without loss of content or function, and reflows to a 320 px viewport without horizontal scrolling
• Line height, paragraph spacing and letter spacing can be adjusted by the reader without text being clipped
• Body measure is capped around 70 characters, which helps dyslexic readers and everyone else
• Wide tables scroll inside their own container rather than forcing the page sideways
• lang="en" is declared so screen readers pronounce the content correctly

Independence from JavaScript

• All content is present in the HTML. With JavaScript disabled you lose the animations, the blog filter and the theme toggle, but every word, link and the contact form remain usable
• No content is hidden behind a script that must run first

Technical specifications

Accessibility relies on HTML, CSS, JavaScript, WAI-ARIA and SVG. The site uses no plugins, no Flash, no PDFs in the main journey and no third-party embeds.

Compatibility

The site is designed to work with current versions of:

Very old browsers — anything predating CSS custom properties — will render the content readably but without the intended design.

Known limitations

Being honest about the gaps is more useful than claiming there are none.

How this was assessed

Self-evaluation, using a combination of:

• Automated checks with browser accessibility tooling across every page
• Manual keyboard-only walkthroughs of every page and interaction
• Screen-reader passes on the homepage, an article, a service page and the contact form
• Contrast checks on every colour pairing in both themes
• Reflow testing at 320 px, and zoom testing to 400%
• Verification that the site remains usable with JavaScript disabled and with reduced-motion enabled

Tell me when it fails you

If any part of this site is difficult or impossible for you to use, I want to know — a real report from a real user beats any automated audit.

Email [email protected] with the subject “Accessibility”. It helps if you can include the page, what you were trying to do, and what technology you were using, but please do not let missing details stop you writing.

If you need any content on this site in a different format — plain text, large print, or read aloud on a call — just ask. There is no charge and no form to fill in.

Escalation

If you are not satisfied with my response, you can raise the matter with the New Zealand Human Rights Commission, which handles complaints about disability discrimination. I would much rather resolve it directly, but you should know the option exists.