European Accessibility Act: A Tech Communications Guide

When is an accessibility claim ready for the press?

An accessibility claim is ready when the team can show what it tested, what worked and where the limits remain. The press copy must match that evidence. A launch date, a strong demo or a high scan score cannot fill a gap in the record.

Accessibility means reducing the barriers that prevent disabled people from using a product or service. In a launch, this can involve both the product and the way you explain it. A phone may support speech output while its press kit remains hard to read.

The European Accessibility Act, or EAA, is the common name for Directive (EU) 2019/882. EU countries put its rules into national law. It covers certain products and services, rather than every business website in the same way.

This guide proposes a press approval process, not a legal test or a certificate. Your legal and product teams must resolve the rules that apply in each market. The communications team's job is to keep public claims within the facts those teams can support.

What should the approval file say about scope?

The approval file should name the product, release, market and task behind each claim. Start with what a customer will receive, not the broad name of the brand. A claim about one release should not quietly become a promise about the full product range.

The EU guide to accessible goods and services explains that the Act applies from 28 June 2025. Its scope includes selected goods and services, such as smartphones, payment terminals and e-commerce. Exceptions also exist. Ask a qualified legal reviewer to assess them against the actual business model.

Consider a fictional Turkish firm that sells checkout software through a partner in Germany. One team builds the product, another hosts the service and a third handles support. Before a launch, establish which claims each team can approve. A shared logo does not remove these different roles.

Record five things before anyone writes the press release:

• The release: Give the exact product name and version being announced.
• The market: State where it is offered and which language customers use.
• The task: Define what a person can do, from sign-in through to completion.
• The limit: List excluded releases, untested steps and known barriers.
• The owner: Name the person who can show the evidence and approve the wording.

Check this file against the sales deck and the partner's product page. If one says “all devices” while the other names two tested devices, resolve the gap. Do not leave the reader to guess which version is true.

A country review should also cover the practical promise of support. An English press release does not prove that English help is available. Check the language, opening hours and route to the team that can solve the problem.

How do you turn a test result into a fair claim?

Describe the tested task and its limits instead of making a promise about every user. “Works for everyone” is a much broader claim than a report about one flow. Strong copy can be precise without sounding cold or defensive.

A screen reader is software that presents screen content through speech or Braille. In a fictional test, a user might complete sign-up with a named screen reader and browser. That result does not cover a password reset unless the team tested it too. Keep those facts separate.

Build a claim log with one row for each proposed statement. Add the supporting report, test date, release and reviewer. Include the exact wording approved for use. This lets a press officer check a sentence without reading every technical file from scratch.

The W3C guide to evaluating web accessibility makes a key distinction: no tool alone can establish whether a site meets the standards. Skilled human review is needed too. Use scan results as part of the evidence, not as a substitute for that review.

WCAG means Web Content Accessibility Guidelines. These guidelines set testable criteria for web content. When citing a WCAG 2.2 assessment, name its level, version and scope. Do not turn a web-content result into a claim that every legal duty for a product has been met.

Ask what happened when a task failed, not only how many checks passed. A short failure note can show the blocked step, its effect and the proposed fix. It helps the press team avoid a claim that conflicts with a known user problem.

Evidence also has a useful life. A report about an earlier release may not support a new sign-in flow or payment screen. Set a review trigger for those changes. The person who owns the product should flag when an approved claim needs another look.

How should the press kit and spokesperson use the evidence?

The press kit and spokesperson should use the same approved claim log. Formats may change, but the facts and limits should not. A social caption must not promise more than the full release, simply because it has fewer words.

Give reporters a readable web version of the core facts. Explain key images in text and plan captions for video. Where important visual information is not spoken, consider how to make it available through sound. A transcript is useful but does not meet every video need on its own.

Choose a demo that shows a real task rather than a polished sequence of screens. State if the demo uses a test build. Give the reporter a clear route to ask about parts that are not shown. Do not imply that a short display tests the whole service.

FL PR & Communications' creative design and content service covers video, sound and formats for different channels. That published scope suggests a useful planning question: who checks each format before release? It is not evidence that a product has passed an access audit.

For the interview, rehearse the hardest question first: “What still does not work?” A useful answer names the known limit and the next step. If the spokesperson does not know, they should offer a clear follow-up rather than guess.

Bring the product expert into that rehearsal. Ask them to explain one result in plain language, then let the press officer test whether the wording stays accurate. Media relations and spokesperson preparation should support this exchange, not replace technical review with a stronger slogan.

A bounded FL example: The Liv Hospital case study is FL's own account of presenting scientific topics across markets. A publisher-hosted KABAR case report contains named doctors' views and FL's media contact details. This verifies a publication record, not its commercial terms, total reach or EAA compliance.

The lesson is about the kind of proof a link provides. A live news story is not a product test. Nor does a product test secure earned coverage, where an editor decides what to publish. Keep paid placements and press-release republications clearly separate in the results report.

Which seven checks should hold or release the announcement?

Release the announcement only when scope, evidence, formats, language, the spokesperson, support and correction ownership are clear. These seven checks are a proposed team workflow. They are not seven duties named by the Act.

1. Confirm scope. Product and legal owners agree which release and markets the wording covers.
2. Match the claims. Each strong statement has a current source and a named reviewer.
3. Check the formats. Review the live web page, download and video as separate outputs.
4. Review each language. Read Turkish and English on their own merits while keeping the same factual limits.
5. Rehearse the answers. Test questions about known barriers, missing evidence and the date of the next update.
6. Try the help route. Send a request from outside the team and check that the right person receives it.
7. Assign corrections. Name who will update the site, press kit, social posts and partner copies.

Give each check a status and a short reason. “Ready” should point to a record. “Hold” should name the missing fact or failed test. A team can then solve the specific issue rather than debate whether the campaign feels finished.

For example, a caption file may be missing while the product test is complete. Hold the video until the file is checked. Do not use that gap to declare the whole product unlawful; equally, do not wave it through because the launch is tomorrow.

If you buy outside help, ask what the fee covers. A proposal should separate product testing, content review, legal advice and press work. Check who owns fixes and whether another review is included. “Accessible launch package” is too vague to settle these questions.

Schedule the final review early enough to make changes. A correction request at the moment a release is due encourages weak decisions. Share one approved master file with partners, and record which version each received.

What should happen if a barrier appears after launch?

First establish what the person cannot do, then correct the affected claim and channels. The right response depends on user impact and legal duties. Not every defect calls for withdrawing the full launch, but a false claim should not remain in use.

A payment button without a useful name may leave a person unable to buy. Calling it a minor label issue misses that impact. Describe the task, not just the code fault. Test any interim route before telling customers to use it.

A correction notice can be brief. Name the affected release, the known problem and the help route. Give a fix date only when the responsible team can support it. Otherwise say when the next status update will be provided.

Tell reporters and partners who received the old claim. Quietly changing the download will not update copies already in use. Explain what changed and give a direct link to the revised file.

Measure the process as well as the coverage. Count unsupported claims caught before release, blocked tasks, time to first reply and time to a tested fix. Track how long it takes to replace old copy across channels. These measures answer different questions; do not merge them into one success score.

Use recurring faults to improve the approval process. If translations often widen a claim, add a review at that handover. If support cannot find the test owner, fix the contact route. Related decision guides in the FL PR expert insights archive can support that wider review.

Frequently Asked Questions

A fair claim stays within the evidence and makes unresolved points clear. These four answers cover common decisions in the approval process.