Accessibility Statement
Accessibility is not a feature I added. It is most of the reason this exists.
I build these tools because systems were not designed around real lives, mine included. It would be a poor joke to then build something people cannot use.
This page sets out what we currently do, what we are still working on, and how to tell us when we have got it wrong. It is written to be honest rather than impressive.
What we aim for
We work towards WCAG 2.2 Level AA as a minimum across the website and the tools we build.
In practice that means:
- Text you can resize without the page falling apart
- Colour contrast strong enough to read in bad light and on bad screens
- Everything reachable by keyboard, with a focus indicator you can actually see
- Labels that make sense when read aloud by a screen reader
- Text alternatives for images that carry meaning
- Captions and transcripts for video and audio
- No information communicated by colour alone
- A reduced-motion option
- Touch targets big enough for hands that do not always cooperate
Plain language counts as accessibility
A page that meets every technical requirement and is still written in policy language is not accessible.
We write in plain English. We explain system terms rather than assuming them. Where something is genuinely complicated, we say so instead of pretending it is simple.
Formats
Where we can, we offer material in more than one form: Easy Read versions with shorter sentences, printable versions of planning tools, and downloadable documents you can use offline.
If you need something in a format we have not produced, ask. I would rather make one for you than have you go without.
Designed with disabled people, not for them
Tools are shaped by what comes up in co-design work, community conversations, and testing with the people who will actually use them, including disabled people and people with chronic and rare conditions.
That is not a marketing line. It is how the content ends up being right.
What we have checked, and what we changed
In September 2026 we went through this site properly rather than assuming it was fine. What we found and fixed:
- Colour contrast. Every text and background combination on the site was measured against the WCAG 2.2 AA thresholds. Three combinations failed: the small “Coming soon” label on the teal band, the section labels sitting on our pale blue bands, and one paragraph set in slightly transparent white. All three are fixed, and our deep teal is now marginally darker so it passes comfortably in every place it is used.
- Reduced motion. The site now respects your operating system’s “reduce motion” setting, so animations and transitions stop if you have asked your device to keep things still.
What we confirmed was already working: the page language is set correctly for screen readers, there is a “skip to content” link for keyboard users, every form field has a properly linked label, the required-field asterisks are hidden from screen readers so they are not read as stray punctuation, decorative icons are hidden from screen readers, the mobile menu reports whether it is open or closed, and every image carries a description.
Where we are not there yet
Being straight with you:
- Our contrast and code review was done by us, not by an independent accessibility auditor. An independent audit, including testing with screen reader users, is planned and has not happened yet.
- Some older posts predate our current standards and may not meet them.
- Third-party services we rely on, such as email and payment systems, are not fully under our control. Where we know of a barrier, we will say so.
- Easy Read versions do not exist for everything yet.
I would rather publish this honestly than claim a standard we have not met. This section will be updated as things change, and it will say what we fixed.
Tell us when we get it wrong
If something here does not work for you, please tell us. You do not need to be technical, and “this bit was confusing” is genuinely useful.
Email hello@lighteningup.com.au and tell us what you were trying to do, what happened, and what you were using if you know it. We will reply, and we will tell you either when it is fixed or why it is taking longer.
We treat accessibility problems as faults, not feature requests.
Last reviewed 18 September 2026. We review this statement at least once a year, and whenever we release something significant.