I didn’t want a clickbait title, but here's 3 accessibility prompts I actually use
Well, that went well.
I wasn’t planning to use AI for accessibility. It just didn’t seem like the kind of thing it would be very good at. Too many grey areas, too much context. I’d seen it hallucinate before and figured I didn’t have time to double-check everything it spat out. The last thing I wanted to do was to have something so important to so many people, left in the hands of a bot that could never understand their personal situations.
But then I started using it quietly. Not for anything critical. Just the time consuming fiddly bits. And it turned out... well, not bad.
It didn’t do the work for me, but it helped nudge things along a bit. It saved my time and got me thinking about things I hadn’t previously considered.
So I started saving the good ones. Prompt after prompt, with little notes and caveats and occasional swearing at myself, and I soon realised that I had close to 50 of them. I started to organise them and pull out the better ones, remove the repeats (of which there was a lot) and documented the way I use them.
Eventually I had a pack of around 20 that I regularly use, and that’s what I’m now selling over on Gumroad. Well, I say selling. I mean a few people have looked at it but it’s not exactly going to pay off my mortgage.
I wanted to share three of my most used prompts because they’ve made things a bit easier for me, and maybe they’ll do the same for you. And if they do, obviously I’d love you to check out the pack (or even recommend it to others), but at the very least maybe it will help you understand how AI can be useful when used properly.
You don’t need to believe in AI as some sort of saviour to get a bit of value out of it. Sometimes, it’s just a small win on a long day.
So let’s get to the nitty gritty...
Alt Text Helper
Simply put, this prompt does exactly what it says on the tin - it helps you write better alt text. It’s tuned for real use - meaning it doesn’t just describe what’s in the image, but what that image is for. Why it’s there. What the user actually needs to know.
I use it when I’m uploading blog images, checking other people’s work, and occasionally for fun. I may be 50, but I’ll always be a younger brother, and having AI describe a photograph of your sibling as “old” will always be amusing.
It’s not perfect. You still need to judge whether it’s picked up the right nuance. But it’s good enough to get you out of “I’ll come back to that” mode. And more often than not, it nails it.
I'm going to upload an image or provide an image URL. When I do, I want you to act as an **accessibility expert** who specialises in writing high-quality, meaningful alt text for real users.
Your goal is to describe the image in a way that conveys its **purpose, message, or function** – not just what it looks like.
This alt text will be used by people who rely on screen readers, so it needs to be clear, informative, and focused on what matters most in context.
Please follow these instructions carefully:
- Assume the user **cannot see the image** – what do they need to know to understand its meaning or value?
- Focus on the **function** or **message** of the image, not surface-level visual details unless they're essential.
- Use **concise British English** that’s easy to follow and screen reader–friendly.
- Keep it to **one sentence** if you can, or two short ones if needed – no more than **150 characters total**.
- Avoid phrases like “image of” or “photo showing” unless they’re truly necessary for clarity.
- If the image includes visible text, summarise it **only if** it adds important context.
- Return **only the final alt text** – no labels, no explanation, no headings.
Wait until I upload the image or provide a URL before generating your response.Mobile Interaction Check
You know that feeling when a button’s just slightly too small, or you try to tap something and your thumb hits the wrong link? Now imagine doing that with motor impairments, or while using assistive tech. This prompt helps spot that kind of friction early.
It’s not magic. It can never replace proper testing. But it gives you a decent review of whether a mobile interface might be awkward or outright hostile for users who can’t tap with pixel-perfect precision.
I use it for checking touchscreen flows during QA or design sign-off. Works nicely when paired with a screenshot or URL. At the very least it helps generate an important conversation before development begins.
I need you to review this user interface for accessibility barriers specifically affecting people using **touchscreen devices**. Please assess it with the needs of users who have **motor limitations, tremors, or reduced precision**. Your review should include the following:
- **Touch target size and spacing** – Are buttons, links, and controls large enough and far enough apart to avoid accidental taps?
- **Gesture reliance** – Does the interface require complex gestures like swipes, pinches, or long presses? If so, are there alternatives?
- **Pinch-to-zoom and responsiveness** – Can users zoom in if needed? Does the layout respond well to different screen sizes and orientations?
- **Tap area clarity** – Are interactive elements clearly indicated as tappable and easy to activate with one finger?
Then, suggest **practical, inclusive changes** to improve usability for people with reduced motor control. Recommendations should be specific, WCAG-aligned where possible, and explained in plain English.
[Upload a screenshot, or link to the webpage.]Accessibility Checklist
This one’s a bit of a Swiss Army knife. I use it when I’m planning new work, reviewing a wireframe, or handing something over to a designer who wants to check their own thinking before it hits development. It’s not revolutionary, but it’s solid. Saves you from having to dig through WCAG again or repeat the same reminders you’ve given ten times already.
The nice bit is that it covers both technical and human-centred checks - not just “are the colours compliant?”, but things like “would someone with ADHD know where to start?”.
I usually ask it to tailor the checklist to whatever I’m working on - a form, a homepage, a blog post. And I’ve used the same prompt to create short “content-only” versions too. It adapts surprisingly well.
The goal isn’t just to tick boxes. It’s to slow down and think: is this working for everyone? Or are we accidentally baking in problems we’ll need to fix later.
I'm redesigning a web page and want to make sure accessibility and inclusive design are considered from the start.
Please create a **comprehensive checklist of accessibility considerations**, based on **WCAG 2.2 AA standards** and **inclusive design principles**.
The checklist should:
- Be suitable for use by designers, developers, and content editors
- Be grouped by topic (e.g. structure, navigation, colour, media, interactions, forms, content)
- Use clear, plain English suitable for a general team
- Include both **technical checks** (e.g. semantic HTML, contrast ratios) and **human-centred design prompts** (e.g. does this work for neurodiverse users, or on a slow connection?)
- Be useful as part of an internal design QA or planning document
- Focus on **preventing barriers before they’re built**, not just fixing them later
- Use British spelling throughout
Where relevant, reference the WCAG success criteria (e.g. “SC 1.4.3”) and note if something is a best practice rather than a strict requirement.If any of these turn out to be useful, I’ve put together a full pack with 22 prompts like this - covering things like colour contrast, keyboard navigation, accessible forms, and a few odd ones I didn’t expect to rely on. It’s up on Gumroad if you're curious.
But more importantly - if you’ve been playing with AI in your own accessibility work, I’d genuinely love to hear what’s worked (or not worked) for you. Got a better prompt? A weird use case? Something that completely backfired? Drop it in the comments. I’d be thrilled if this became a bit of a messy, shared experiments thread rather than just me talking into the void.