Forklist

Accessibility

Forklist should work if you use a screen reader, if you never touch a mouse, if colour is not how you tell things apart, or if things moving on a screen make you ill. Here is exactly where that stands.

Accessibility statement · last reviewed 14 August 2026

The commitment

Forklist should be usable by everyone it is for, and being small is not a reason to skip that. Accessibility is treated here as part of whether a feature is finished, not as a pass done afterwards — a screen that cannot be reached from a keyboard is not a screen that is ready. Where the app falls short of that, this page says so by name rather than leaving you to discover it.

The standard being worked to is WCAG 2.2, Level AA.

The honest version

Forklist is one person, working evenings. There is no accessibility team here and no consultancy on retainer, and nobody has yet sat down with this app and a screen reader and told me what it is like.

So read everything below as measured rather than proven by the people it is for. What I can promise is that these were checked instead of assumed. Every colour in the app was put through a contrast calculation against the surface actually behind it — twelve combinations that looked fine to me failed, and every one of them was changed. That is the standard for what goes on this page: things I went and verified.

What is here today

Seeing

Hearing

There is no sound anywhere in Forklist. No video, no voice notes, no autoplay, no notification chime. Nothing here needs captions or a transcript. That is a much smaller promise than a video platform can make, and it is a completely honest one.

Keyboard, and not using a pointer

Motion, and how much is going on

What is not done yet

I would much rather list these than have you discover them.

What you need to run it

Forklist is a website, so it inherits whatever your browser and your assistive technology can do. It is built against current web standards rather than against any particular screen reader, and the practical version of that is:

What other people write

Most of what is on this map was typed by somebody else, and that part is not mine to guarantee. A note can be up to 500 characters of ordinary prose, and nothing stops it being written in a way that is hard to follow.

What the app does do is keep the structure around it predictable. Notes carry no images, so there is no missing alt text to trip over. Messages are picked from a fixed list, so a conversation is always readable. Tags come from a set vocabulary rather than free text, so filtering never depends on how somebody spelled something. The parts a person can make inaccessible are deliberately small.

Consultation

Every large platform's accessibility page has a section here about their disabled users' advisory group and their external audit partner. Mine says: there has been no consultation. Nothing on this site has been reviewed by a disabled person, an accessibility specialist, or anyone but me.

That is the single biggest gap on this page, and it is not one I can close by writing more code. If you use a screen reader, a switch, voice control, or a magnifier, and you would be willing to spend twenty minutes telling me what this app is actually like — that is worth more than everything else on this page put together, and I would like to hear from you.

Reporting a problem

If something here does not work for you, say so, and be as specific as you can stand to be — what you were using, what you expected, and what happened instead. "The Friends tab announces nothing" is worth more to me than a hundred passing automated checks.

How to reach me

What happens then

What has actually changed

A promise to improve is worth what the record behind it is worth, so here is the record. It starts the day the work started; it is not backdated to look longer.

14 August 2026
The first deliberate accessibility pass, and this page.
  • Measured every text colour in all twelve theme-and-mode combinations against the surface behind it. Twelve failed at AA — the placeholder grey in every theme, which had been compared against the wrong background — and all twelve were corrected.
  • Removed the skip link from every page. It had been added so the first Tab offered to jump past the masthead; it is no longer part of the site, and this entry stays so the record of what changed is complete.
  • Finished the tab pattern. Ten controls announced themselves as tabs and then pointed at nothing, which tells a screen reader there is a relationship and declines to say what it is; they now name the panels they actually control.
  • Gave five inputs a real accessible name instead of leaning on a placeholder, which disappears exactly when you start needing it.
  • Gave the app a top-level heading. The whole application document had none, so a screen-reader user had nothing to land on.
  • Hid decorative icons from the accessibility tree, so buttons announce their name rather than their name and an unlabelled graphic.
  • Extended reduced-motion support to the marketing pages, which animated on hover and never asked, and made loading placeholders go flat instead of shimmering.

Who is responsible

One person builds Forklist, and that same person is accountable for this. There is nobody to escalate past and nobody to hide behind — if something on this page is wrong, it is wrong because I got it wrong.

This page is reviewed whenever the app changes in a way that touches anything on it, and the log above is updated at the same time. If it starts going stale, that is worth reporting too.

Get hold of me