Motta Industries Blog

A customer encounters a barrier on your website and looks for help. The accessibility page says your business values everyone, but it does not identify the affected service, explain known limitations, or provide a useful way to get assistance. The statement sounds considerate while leaving the customer with the same problem.

A website accessibility statement can do more. It can explain what has been assessed, what remains difficult, and how someone can reach the right team. Trust comes from that useful honesty and follow-through, not from publishing a broad claim that the business has not established through appropriate evidence.

Write for the person trying to use the service

Begin with what a visitor needs to know when something does not work. Which website or application does the statement cover? What support is available? How can the person report a barrier? What limitations are already known? A statement should help someone make progress, not require them to understand your procurement history.

W3C’s November 2018 guidance on creating accessibility statements describes statements as information about accessibility, commitment, assistance, and known limitations. It also explains that content depends on the organization and relevant policy. A generated draft is a starting aid, not an evaluation of the website or proof that the answers entered are true.

For a fictional repair business, the statement might need to distinguish the main service pages from an embedded booking tool and downloadable instructions. That is a scope question before it is a writing question. Customers should not have to guess whether a reassuring claim includes the part of the service they cannot use.

Do not copy another organization’s promises. Motta Industries’ website accessibility page concerns its own website, not an assessment of yours. Your statement needs your actual scope, evidence, support route, and responsible owner. Replacing a company name in borrowed wording does not supply those facts.

Separate an accessibility statement from a conformance claim

A commitment to improve is not the same as a finding that a defined website conforms to a particular standard. Make the distinction visible. If an evaluation has not been completed, do not imply otherwise through a seal, a percentage, or a sentence copied from a template.

WCAG 2.2 sets out requirements for conformance and information needed when making a conformance claim. It also addresses complete pages and complete processes. Testing a homepage or one control is not a basis for claiming that an entire booking or purchase journey satisfies the standard.

Name the relevant standard and level accurately when the evidence supports doing so. Explain the scope and basis of the statement without converting a limited review into a universal conclusion. An automated report, one successful task, and a comprehensive evaluation answer different questions and should not be described interchangeably.

Seek qualified advice about legal duties and required wording in the jurisdictions and services involved. This article does not determine whether a particular business must publish a statement or what legal effect a statement has. It does not offer wording that prevents complaints, removes obligations, or substitutes for fixing barriers.

Use models without importing the wrong legal context

The European Commission’s 2018 model accessibility statement provides a structured example covering scope, status, inaccessible content, preparation, feedback, and enforcement information. Its legal context is public-sector websites and applications under the separate EU Web Accessibility Directive, not a universal rule for every private business worldwide.

That distinction matters when a small company borrows a model. A public body’s enforcement route may not be yours. A listed exemption may require an assessment that your business has not made. A statement should not reproduce an official-looking legal category simply because the template includes it.

The model’s emphasis on accurate declarations and identifying the preparation method is nevertheless useful discipline. Ask what evidence supports each substantive sentence. If the business cannot explain the basis for a claim, revise it, obtain the appropriate assessment, or leave the unsupported claim out rather than polishing its presentation.

Keep statements, legal applicability, and technical evaluation connected but distinct. A developer can help inspect and repair the interface. A business owner must approve service commitments. Qualified advisers may need to assess legal requirements. None of those roles should be silently replaced by a generator or a generic statement supplied with a theme.

Describe limitations in practical language

A useful limitation identifies the affected task and what difficulty a person may encounter. Internal issue numbers or unexplained technical terms rarely help a visitor decide what to do. Describe the problem as clearly as the available evidence permits without exposing private information or pretending the issue affects every user identically.

For the fictional repair business, an evaluation might identify a specific problem in the booking journey. Until there is an actual finding, the business should not invent one for the statement. Once a barrier is verified, explain its scope and any appropriate alternative route in language the customer can use.

Do not imply that outsourcing a component removes the customer’s difficulty or resolves the business’s responsibilities. Identify the dependency and the route for remediation. Customers experience the integrated service, even when different organizations control different parts. The statement should make help clearer rather than distribute blame among suppliers.

Motta’s UI and UX design service can help examine the interaction around an affected task and communicate findings to the people responsible for changes. A clearer explanation does not repair the barrier by itself, so connect the statement’s limitations with an actual improvement process.

Offer a feedback route that reaches someone

A feedback mechanism needs an owner, a workable intake process, and an appropriate response. Do not publish an address or form that nobody monitors. If the main contact form is itself affected by a barrier, consider another suitable route that the business can sustain rather than sending people back through the same obstruction.

Ask only for information needed to understand and address the report. The person should not have to provide a medical history or prove a disability before the business considers an ordinary website difficulty. Handle any personal information appropriately and avoid turning a public statement into an invitation to disclose sensitive details unnecessarily.

Set expectations the team can meet. If the business publishes a response commitment, make sure the responsible staff and process support it. Do not confuse acknowledging a report with resolving the issue. Some fixes require investigation or supplier work, and the customer needs an honest account of what happens next.

Check the route with approved, invented examples before publication. Can the team recognize an accessibility report, find the affected part of the service, and pass it to someone who can act? That exercise checks the operating route; it does not demonstrate that the website itself conforms to an accessibility standard.

Make the statement accessible and easy to find

The page offering help should be usable itself. Use a clear title, meaningful headings, understandable links, and a readable layout. Avoid making the statement available only in a difficult document or hiding it behind an interaction that recreates the barrier someone is trying to report.

Consider narrow screens, enlarged text, keyboard operation, and relevant assistive technology interactions. Motta Industries’ responsive design work can address layout across viewing conditions, but responsive behavior alone does not establish accessibility. The actual content and interaction still need appropriate review.

Place a predictable link where visitors can locate it, including from important service journeys where appropriate. Do not make people search a legal archive to discover how to ask for help. The objective is a reachable explanation and route, not merely the existence of a page somewhere in the site structure.

Use the same care when linking supporting reports. Explain their scope and meaning, and ensure that published materials are appropriate for public release. A long technical attachment does not make an overstated summary accurate, and publishing private findings without review can create unnecessary problems.

Date the evidence and assign maintenance

Distinguish the date the statement was prepared from the date of a review or a full evaluation. Those events are not identical. Updating a date should not imply that every page was retested if the team only checked whether contact information remained correct.

Assign a responsible owner and decide which changes require reconsideration. A replacement booking component, redesigned checkout, new document collection, or altered navigation can affect the statement’s scope and claims. Build that review into the change process rather than relying on someone to remember the accessibility page months later.

If a limitation is repaired, verify the relevant behavior before removing it from the statement. If new evidence reveals a different issue, update the description honestly. Do not maintain an optimistic public version disconnected from the team’s current understanding simply because the older wording sounds better.

Keep a proportionate internal record of the evidence and approvals behind important claims. Staff should be able to explain what was checked and what remains uncertain. The public page can stay concise while the business retains the information needed to maintain it responsibly.

Review the statement from both sides of the handoff. A visitor needs a clear description and a useful next step. The person receiving the report needs enough context to investigate and a route to the responsible team. If either side cannot explain what happens after contact, the statement’s reassurance is incomplete.

For businesses serving several markets, check whether support availability and language differ across services. Do not publish one global promise that the local operating process cannot meet. Where separate statements or localized information are appropriate, keep their scope and ownership clear so an update does not leave different audiences with contradictory descriptions.

Be cautious with future dates for repairs. A target can be useful when it is approved and supported by a credible plan, but it is not evidence that the barrier has been removed. If circumstances change, review the public wording rather than allowing an expired commitment to remain indefinitely because nobody owns the page.

Finally, read the draft without relying on the team’s background knowledge. Can someone identify the covered service, understand the status being described, distinguish a limitation from a legal exemption, and locate help? Those questions often reveal where a sincere commitment still needs a more practical explanation. Keep that explanation aligned with the service people will actually encounter today.

Let the statement describe real work

An accessibility statement builds confidence when it is specific enough to help and honest enough to be credible. It should distinguish commitment from evidence, identify its scope, acknowledge relevant limitations, and provide a route that leads to meaningful assistance.

Start with the service customers actually use and the facts your team can support. Then publish an accessible explanation and maintain it alongside the website. The strongest statement is not the boldest declaration; it is the one whose words, support process, and improvement work remain connected.