The prompt
Score 10 of 10, Excellent
Use it when Your website needs an accessibility statement that reports honestly what you tested and what still does not work, with a way for people to get help.
- {{site}}
- {{audience}}
- {{standard}}
- {{testing}}
- {{known_issues}}
- {{alternatives}}
- {{feedback}}
- {{legal_requirements}}
Full prompt and why it works
Prompt
Draft an accessibility statement for {{site}} from our real testing, for {{audience}}, so that people with disabilities can see which standard we aim for, what works, what does not work yet and how to get information or help another way. The statement must describe only what our testing shows, because a statement that claims more than we tested misleads the people who rely on it. The standard we aim for: {{standard}} Our testing (dates, what was tested, how: automated tools, keyboard-only checks, screen readers, testing with disabled users, an outside audit): """ {{testing}} """ Known issues and planned fixes, with dates if we have them: """ {{known_issues}} """ Other ways to get information or services: {{alternatives}} How to report a problem, and how quickly we respond: {{feedback}} Any legal requirement our lawyer has told us to mention: {{legal_requirements}} Use these headings: 1. Our commitment: two or three plain sentences, with no claims about how much we care. 2. How accessible this site is: the conformance status, in the terms our testing supports. 3. What we tested and how: dates, scope and methods. 4. Known problems: a table with the columns Problem, Where, Who it affects, Workaround, Planned fix. 5. Other ways to get help. 6. Tell us about a problem: contact details and response time. 7. When this statement was prepared and last reviewed. Keep it under 600 words, in plain language. For example, a known-problem row might read: "Some charts have no text alternative | annual report pages | people who use screen readers | the figures are in the table below each chart | [date]". That example shows the form only. Rules: - Write "fully conforms", "fully compliant" or "fully accessible" only if our testing notes show that every page was tested against every criterion of the standard with no failures. Otherwise use "partially conforms" and say what was not tested. - Do not invent fix dates; write "date not set" where we have none. - Do not name any law unless the legal requirement above names it, and do not say the site meets it. - Avoid phrases like "we are committed to excellence"; say what we do. If the testing notes do not give a date, or the scope of testing is unclear, write [DATE] or [SCOPE TO CONFIRM] in the statement and list the gap for me above it.
Variables
- {{site}}
- The website or app, for example "our online store".
- {{audience}}
- Who reads it, for example "visitors to our website, including people who use assistive technology".
- {{standard}}
- The standard you aim for, for example "WCAG 2.2 level AA".
- {{testing}}
- What you tested, when, how and with what results, including any audit report summary.
- {{known_issues}}
- Problems you know about, where they are, and planned fixes with dates.
- {{alternatives}}
- Other ways people can get information or buy, for example "phone orders during business hours".
- {{feedback}}
- How people report a problem and how quickly you respond, for example "email [address]; we reply within 2 business days".
- {{legal_requirements}}
- Any law or requirement your lawyer said to mention, or "none".
Why it works
- What to avoid. The words "fully conforms" appear only if your testing covered every page and criterion, because an overstated accessibility claim misleads the people who depend on it.
- Format. A known-problems table with workarounds and planned fixes tells readers what will not work for them and what to do instead.
- If unsure. Missing dates and an unclear testing scope get markers and a note to you instead of a guessed date.