Event accessibility statement template: say what is verified and how to ask
An event accessibility statement should help a person decide whether and how they can participate. The first result for “conference accessibility statement template” provides copy-ready notices for registration, confirmation and pre-event messages. Our original template follows those useful placements but makes verification the first step: name real access features, describe known limits honestly and give a monitored request route. This is attendee information, not a website WCAG conformance statement or a record of any individual’s private request.
Boletolibre editorial team
Published
Verify the facts before making promises
Ask the venue and relevant service providers to confirm the actual route from arrival to participation: entrances, lifts, seating, toilets, parking or drop-off, hearing or captioning support, quiet space, virtual participation and emergency assistance where relevant. Record what is confirmed, who checked it and when. A feature planned but not contracted or tested should be described as pending, not available. If an access route has a known barrier, state the practical limitation and the contact for an alternative. Cornell emphasizes checking the site and responding to requests; no generic template can certify a particular event.[2]
- Confirmed feature: exact location, hours and who verified it.
- Known limitation or change: what the attendee may encounter and whom to contact.
- Unconfirmed claim: hold from publication until evidence exists.
Write for the attendee, not for the approval file
Use a short notice on the event page and registration form, then a fuller page with verified access information. Give a monitored email, phone or other usable contact and say how the team follows up. Ask what support would enable participation, rather than asking for a diagnosis. Keep dietary requests separate when different teams handle them. If some arrangements need lead time, state an honest preferred contact date while keeping a route for later questions. Dryfta’s leading guide separates the event statement from the private request and from software accessibility claims; UW–Madison also treats a brief accessibility tagline as a way to explain how to ask.[1][3]
Repeat the useful route at each touchpoint
Link the full information from the event page and place a brief notice next to registration. The confirmation should repeat the contact route and explain what happens to any pending request. Before the event, update practical details that have changed, such as the entrance or transport stop. Use the same current version across languages and channels, but do not simply translate a promise that has not been verified for the relevant session or location. W3C’s separate website-statement guidance likewise favors plain language, known limitations and an easy-to-find contact; it does not establish that the physical event is accessible.[1][4]
Download the original editable wording
The text file contains a short registration notice, a full event access information block and a confirmation reminder. Replace every bracketed field and delete any optional feature you cannot verify. Have the venue and request-response owner review it, then test the links and contact channel before publication. Keep the version current when venue arrangements, vendors or programme details change. The wording is an editorial aid, not an approval or legal determination.
Sources and further reading
- Conference Accessibility Statement TemplatesDryfta · Accessed
- Accessible Meeting and Event ChecklistCornell University · Accessed
- Guide to Accessible Tagline StatementsUniversity of Wisconsin–Madison · Accessed
- Developing an Accessibility StatementW3C Web Accessibility Initiative · Accessed