ibin

How to write an accessibility statement: steps and example

Draft a clear accessibility statement with the right sections, a practical HTML example, and real findings from your website.

Who needs an accessibility statement?

Belgian public-sector websites and mobile applications must provide an accessibility statement. It explains how accessible the website is, which problems remain, which alternatives are available, and how visitors can provide feedback.

Businesses may also have duties to provide information about the accessibility of covered services. The exact rules depend on the service, organisation, and applicable exemptions. The public-sector statement is therefore not automatically the correct legal model for every business. Use this guide as a practical starting point and have your legal position checked when needed.

Write the statement step by step

  1. Define the scope

    Name the exact website, application, or digital service covered by the statement. Use separate statements when different sites or apps have different accessibility status.

  2. Assess the website

    Combine an automated scan with manual checks, including keyboard use, zoom, forms, and representative assistive technology. Record which pages, templates, and functions were tested. An automated scan alone cannot establish full conformance.

  3. Choose an honest conformance status

    State whether the website is fully, partially, or not conformant with the applicable requirements. Only choose fully conformant when a sufficiently thorough assessment supports it. Describe the standard and audit method without claiming more certainty than the work provides.

  4. Describe inaccessible content

    Group concrete problems in plain language. Explain where they occur, who may be affected, and, where known, which criterion is not met. Do not paste hundreds of technical lines into the statement: link to the report and summarise the important patterns.

  5. Give alternatives and an improvement plan

    Explain how people can access the information or service another way in the meantime. Name who owns the fix and give a realistic target date. Be honest when no alternative or date is available yet.

  6. Add feedback and complaints routes

    Provide an accessible contact route for reporting a problem or requesting information in another format. Public bodies should also include the applicable complaints and enforcement procedure.

  7. Publish and maintain the page

    Publish the statement as a regular HTML page, link to it clearly from the footer, and include its preparation and revision dates. Update it after an audit, significant change, or resolved accessibility problem.

What should it contain?

  • The organisation and exact website, app, or service covered.
  • The conformance status and standard or legal requirements used.
  • The assessment method, tested scope, date, and a report link where available.
  • A concrete list of inaccessible content and relevant criteria.
  • Available alternatives and a credible improvement plan.
  • Contact details for reporting accessibility problems.
  • The complaints and enforcement procedure where applicable.
  • The date the statement was prepared and last reviewed.

Concise HTML example

Use this as an editorial starting point. Replace every item in brackets and adapt the legal wording to your organisation. Do not publish a conformance status that your assessment does not support.

<main>
  <h1>Accessibility statement</h1>
  <p>[Organisation] wants [website or service] to be accessible to everyone.</p>

  <h2>Scope of this statement</h2>
  <p>This statement applies to [complete URL or application].</p>

  <h2>Conformance status</h2>
  <p>[Fully / partially / not] conformant with [applicable standard].</p>

  <h2>Inaccessible content</h2>
  <ul>
    <li>[Problem, location, impact, and criterion where known]</li>
  </ul>

  <h2>Alternatives and improvement plan</h2>
  <p>[Accessible alternative, planned fix, and target date]</p>

  <h2>Preparation of this statement</h2>
  <p>Prepared on [date] following [internal/external and simplified/in-depth audit].</p>

  <h2>Feedback and contact</h2>
  <p>Report a problem through [accessible contact route].</p>

  <h2>Complaints procedure</h2>
  <p>[Internal complaints service and applicable enforcement body]</p>

  <p>Last reviewed on [date].</p>
</main>

Start with real findings from your website

An initial scan helps identify recurring technical problems and makes the “inaccessible content” section concrete. Treat the results as an inventory, not an automatic conformance statement. Supplement them with manual testing and editorial knowledge of the website.

For example yourshop.com. One page takes about 20 seconds and it is free.

What an automated scan cannot decide

The scan cannot decide by itself that your website is fully conformant, that an alternative is usable, or that a complaints process is legally correct. It also cannot find every issue involving keyboard use, understandability, video, documents, or assistive technology. Have the final statement reviewed by someone who understands the website, its users, and the applicable framework.

Frequently asked questions

Is an accessibility statement mandatory?
It is mandatory for Belgian public-sector websites and mobile applications. Businesses may have different accessibility and information duties depending on their services, so check the framework that applies to your organisation.
Is an automated scan enough?
No. A scan finds common technical patterns but cannot prove complete accessibility or legal conformance. Combine automated results with manual testing and review of content and processes.
Can I say that my website is fully conformant?
Only when a sufficiently thorough assessment supports that conclusion. When known problems remain, “partially conformant” with a concrete list, alternatives, and an improvement plan is usually more honest and useful.
How often should I update the statement?
Review it regularly and whenever an audit, significant website change, or resolved finding changes the status it describes. Always show the latest revision date.

Official sources and tools

Also available in Nederlands, Français, Deutsch