Why EU-Funded Projects Need Content Infrastructure Before the Grant Is Won
Insights / EU project communication Why EU-Funded Projects Need Content Infrastructure Before the Grant Is Won The communication problem in an EU-funded project usually becomes visible after the proposal has succeeded. Olena Soinikova · Content Infrastructure · 04 October 2026 On this page From proposal to implementation Communication vs dissemination When results do not travel The work package gap Content as reporting infrastructure Infrastructure should match the project What happens after project closure Designing the operating system Sources and resources The communication problem in an EU-funded project usually becomes visible after the proposal has succeeded. By then, however, many of the decisions that created the problem have already been made. The consortium has defined target groups and communication activities. Responsibilities have been distributed across work packages. Deliverables have deadlines. Somebody has estimated the communication budget and described how results will reach the relevant audiences. Then implementation starts.A pilot finishes in one work package, while the useful numbers sit with another partner. Photographs from an event are stored locally. The technical explanation appears in a deliverable that reaches the communication team several weeks later. By the time somebody decides that there is material worth publishing, part of the context has already disappeared. Working across several EU-related projects at the same time has made this gap increasingly visible to me.Projects rarely lack communication channels. The weakness is usually further upstream: the proposal defines what communication should achieve without necessarily designing how project knowledge will move between partners once delivery begins. I use “content infrastructure” for that operating layer.And I think it needs to be designed before the grant is won, even though most of its weaknesses will only become visible afterwards. The proposal describes communication. Implementation has to produce it. Content infrastructure is not a term used in EU funding rules. I define it as the organisational and technical system that converts project activity and results into approved, accessible and traceable material throughout implementation. The formal obligations come from somewhere else. Under Horizon Europe, Article 17 of the Model Grant Agreement requires beneficiaries to promote the action and its results through targeted information to multiple audiences, in accordance with Annex 1. Horizon guidance treats communication as an activity that starts with the action and continues during implementation. There is another distinction that matters once production begins. The Commission treats communication, dissemination and exploitation as different activities. Communication concerns the project, its work and results. Dissemination makes results available to people who may use them. Exploitation is concerned with actual uptake in research, services, policy, products or other applications. The administrative language hides a fairly practical difference. Publishing a LinkedIn update about a methodology communicates that the work exists. A practitioner finding the methodology, understanding it and being able to apply it is a dissemination outcome. The project may need both, but the production logic behind them is different. Erasmus+ and Digital Europe structure these responsibilities differently, and individual Grant Agreements add their own commitments. There is no horizontal EU rule requiring every funded project to maintain a separate website or publish a fixed number of social posts. Translation into several languages is not a universal requirement either. The operating system therefore has to follow the actual project. Spending on communication does not guarantee that results travel European Court of Auditors Special Report 09/2026 contains a useful example of what can happen when activity and dissemination become disconnected. The audit covered innovation projects under EIP-AGRI/CAP, not Horizon Europe, Erasmus+ or Digital Europe. I would not use its findings to estimate performance in those programmes. The failure mechanism is still worth examining. Of 53 projects in the relevant sample, 49 had expenditure for communication and dissemination. Only 28 published results and shared the knowledge they had created. In a Spanish sample examined by the auditors, dissemination-related expenditure ranged from approximately €40,000 to €79,000 per project and reached as much as 17% of project costs. Six of the ten projects disseminated substantial results considered useful to other practitioners. The auditors also fou nd cases where project websites disappeared or contained little information about achieved results. Reporting could arrive years after project completion. This is more interesting to me than a general argument about communication budgets. The projects had spent money on communication. The weak point appeared in the transfer of results. A consortium can publish regularly and still make its knowledge difficult to find or use. More output does not repair that connection. Work packages produce knowledge differently from the way communication uses it This is where consortium structure starts to matter. EU projects are organised around work packages because the work itself needs ownership. Communication has another organising principle: material has to make sense to a particular audience at a particular point in the project. The useful information is therefore often sitting in the wrong organisational place. A technical partner completing a pilot may quite reasonably consider the task finished once the technical work and required documentation are complete. From a communication perspective, several things are still missing. Somebody needs the relevant facts while they are current, an explanation that works outside the technical team and enough context to decide whether the result belongs in public communication or dissemination. Add several countries and organisations, and this becomes a coordination issue rather than a writing issue. The existence of a communication work package does not resolve it. Formal responsibility can sit with one partner while the source material remains distributed across the consortium. CommuniCity gives a useful public example of a project that treated communication as a recurring process. The Horizon Europe project, Grant Agreement 101070325, received approximately €5 million in EU funding and ran from September 2022 to August 2025. Its public documentation included an early Communication Plan, later updates and Communication Performance Reports during implementation. Planning was followed by monitoring and review rather than ending with the submission of the first communication deliverable. I find the repetition
An EU grant does not create one universal accessibility rule. It does not make accessibility optional either.
Insights / Web & Accessibility An EU grant does not create one universal accessibility rule. It does not make accessibility optional either. What EU-funded project teams need to check before inaccessible websites, PDFs and videos become a monitoring issue. Olena Soinikova · Research & field notes · 18 September 2026 On this page The confusion is understandable Where EU-funded projects sit The practical problem What accessibility-aware means What this does not mean A practical starting point Sources and further reading An Erasmus+ consortium launches a project website. The coordinator uploads the partner logos, adds a project summary, and publishes the site. Six months later, a project officer at the national agency opens the site during a monitoring review and cannot tab through the navigation with a keyboard. The cookie banner covers half the page on mobile. The heading structure is broken. None of the uploaded PDFs have a text layer. Nobody planned for this, and nobody budgeted for it. Six months into a live project, it is a compliance question. The confusion is understandable Accessibility requirements in the EU are spread across multiple legal instruments, and none of them apply to every organisation in the same way. Directive (EU) 2016/2102, the Web Accessibility Directive, applies to public-sector bodies. It requires websites and mobile applications to meet EN 301 549, the harmonised European standard based primarily on WCAG 2.1 Level AA. Public-sector bodies must also publish a detailed accessibility statement and provide a feedback mechanism. The European Accessibility Act, Directive (EU) 2019/882, has applied to covered products and services since 28 June 2025, with certain exceptions and transitional provisions. It covers specific products and consumer-facing digital services: e-commerce, consumer banking, certain transport services, and e-books. It does not mean that every private website in Europe automatically falls under its scope. And then there is the grey area where most grant-funded organisations actually operate. Where EU-funded projects sit There is no single rule that says every Erasmus+ or Horizon Europe project website must comply with the Web Accessibility Directive. The obligation depends on several factors that vary from project to project: the legal status of the beneficiary, national transposition of the directives, procurement conditions attached to the grant, and requirements written into the specific call or grant agreement. A public university will often fall within the public-sector framework, while a privately constituted NGO may not, although legal form alone does not always determine the answer. What does apply universally is a different kind of pressure. Accessibility is relevant across EU digital policy, procurement and publicly funded service delivery, and project officers assess digital deliverables accordingly. A project that publishes inaccessible PDFs, builds a website that cannot be operated without a mouse, or embeds videos without captions is not necessarily violating a specific legal clause. But it is producing outputs that fall below the standard the Commission expects from publicly funded communication. The dissemination and communication section of any Horizon Europe periodic report asks what you did and how you did it. An inaccessible project website is evidence of a communication deliverable that does not meet professional standards. A project officer or reviewer does not need to establish a breach of the Web Accessibility Directive to question the quality, usability or reach of that deliverable. The practical problem is simpler than the legal one Organisations get stuck trying to determine their exact legal obligations. That question matters, and it is worth answering properly with legal counsel or a compliance review for the specific grant agreement and national context. But the practical problem can be addressed separately, and much sooner. Most accessibility failures on EU-funded project websites are not obscure technical edge cases. They cluster in four areas that any team can check without specialist tools. 01 Set up the working system Headings are chosen for visual size, not semantic hierarchy, so screen readers cannot distinguish a section title from body text. Pages often have no skip-to-content link. Keyboard users tab through the entire navigation on every page load. 02 Keyboard and focus Problems show up the moment anyone tries to use the site without a mouse. Menus, modals, cookie banners and embedded widgets trap the keyboard or cannot be reached. Focused elements may be hidden behind sticky headers, while the tab order bears no relationship to the visual layout. 03 Contrast and readability These failures affect many people, including users with no diagnosed impairment. Light grey text on white backgrounds is common. Content breaks at 200% zoom. Essential information lives inside images without alternative text. 04 Forms and interactive content Form fields lack programmatic labels. Error messages say something went wrong without saying what. Videos use auto-generated captions that nobody reviewed. On mobile, the theme disables zoom and menus cover focused content. This is the default state of many WordPress sites built without accessibility as a design constraint. What “accessibility-aware” means in practice The current harmonised European standard, EN 301 549 v3.2.1, references WCAG 2.1 requirements. For new builds, however, WCAG 2.2 Level AA is the more sensible internal design and QA target, regardless of whether a specific legal obligation currently applies to the project. This is a pragmatic decision, not an idealistic one. Accessibility requirements are expanding across EU digital policy, procurement and service delivery. The European Accessibility Act is in force. Designing to a recognised standard now reduces the risk of costly remediation in the next project cycle. The grant ecosystem also rewards it quietly. An accessible, well-structured website signals institutional capacity. Consortium partners checking a potential coordinator’s digital presence before joining a proposal notice the difference between a site that works and one that does not. So do reviewers and project officers. And the cost argument is straightforward: a WordPress site with broken heading hierarchy, missing alt text and inaccessible forms requires a structural review of every template. That is not a quick fix. Organisations that address accessibility at the design stage spend a fraction of what organisations that retrofit spend
Your EU Project Has a Communication Plan. Does It Have a Working Process?
Insights / EU project communication Your EU Project Has a Communication Plan. Does It Have a Working Process? Review audiences, languages, approvals, channels and content infrastructure. Olena Soinikova · Research & field notes · 10 September 2026 On this page Plan and readiness A route to your audience Languages and versions Approval and risk Channels and capacity Content infrastructure Proportionate preparation The practical check Sources and resources A consortium has a communication plan, a project website and two social media accounts. Six months after kick-off, the first substantial result is ready to publish. Then somebody asks for the latest approved project description. Three versions appear in the shared drive. The Greek translation was made from an older English text. Nobody is certain whether the participant photographs can be reused. The colleague with administrator access to the website has changed jobs. The communication plan still exists. So do the website and social accounts. The operating process is less certain. I see this distinction particularly clearly when several EU-related projects are running at the same time. Communication can look organised at planning level while depending operationally on one colleague remembering where something is stored, which translation is current or who needs to approve a publication. I call this communication readiness. In practical terms, it means that a project can produce, approve, deliver, maintain and preserve its communication without reconstructing the process each time. The term is my working framework, not an official EU programme concept. Its components, however, sit underneath many of the communication requirements and recommendations already found across Horizon Europe, Erasmus+, Interreg and other EU programmes. A communication plan documents intent. Readiness tests execution. EU-funded projects already operate within communication and visibility requirements. All recipients of EU funding have a general obligation to acknowledge the origin of that funding and ensure its visibility. Depending on the programme, projects can also face specific requirements concerning communication activities, websites, social media, events, media relations and other forms of public visibility. The European Commission explicitly advises beneficiaries to check programme-specific funding rules and financing agreements for the details. Horizon Europe adds an important distinction between communication, dissemination and exploitation. Communication makes the project, its activities and results visible; dissemination makes results available to people who can use them; exploitation concerns their actual use in further research, products, services, policy or other applications. Erasmus+ takes another route. Its #CommsJourney guidance provides beneficiaries with a step-by-step framework for communicating projects and their results. These frameworks matter. I would not replace them with another homemade compliance system. The operational problem starts one level below them. A communication plan can say that the project will communicate with policymakers, practitioners, SMEs and citizens through a website, newsletters, events and social media. It may still leave unanswered which municipal network can actually reach the relevant policymakers, who checks the Danish version of a new result summary, or whether a routine event reminder needs approval from seven partners. A useful five-minute test is to ask a colleague who did not write the communication plan to find the current approved project description, the correct funding acknowledgement and the latest reusable visual assets. If this requires several messages to several people, I would start there before adding another communication activity. An audience list needs a route to the audience “Policymakers”, “SMEs”, “stakeholders” and “the general public” appear regularly in project communication plans. They are categories. Communication starts when the project can connect those categories to an actual need and an actual route. For one project, a professional association may provide better access to SMEs than a new Instagram account. Municipal actors may already sit inside a partner’s regional network. A community organisation can be more useful for reaching a specific group of citizens than another digital campaign. This is also where communication and stakeholder engagement begin to separate. Making somebody aware that a project exists is different from involving that person in an activity, getting them to use a result or bringing them into a policy discussion. I use a simple chain when reviewing this: Audience → need → message → desired action → realistic route The final part is easy to underestimate. A carefully described target audience that the consortium has no credible way to reach remains largely theoretical. The same principle applies to channel selection. A project should not start with “Should we create LinkedIn, Instagram and Facebook?” It should start with where the relevant people already receive information and which of those routes the consortium can realistically access. Multilingual communication needs a source of truth European projects create an obvious temptation to translate everything. That is rarely the most useful starting point. There is no general rule requiring every EU-funded project to translate every communication asset into every partner language. Programme-specific obligations still need to be checked. Operationally, language decisions should follow the audience: who needs this information, and in which language will they actually use it? Once several versions exist, a different problem appears. The core project description changes in English. The website is updated. The Greek version remains unchanged. A partner translates an older PDF into Danish. Six months later, three technically correct documents describe the same project differently. That is a version-control problem disguised as a translation problem. For multilingual projects, I want to see one identifiable master version, agreed terminology for programme names and recurring technical terms, and a defined review route for every language that matters. Machine translation can reduce the first production step. Responsibility for meaning remains with the project. A concrete starting point takes about twenty minutes: identify the source-of-truth project description, add a version number and date, then list the active language versions beside it. Each needs a defined review route when the master changes. This becomes even more relevant as projects introduce AI-supported translation, synthetic voice and multilingual video. Production capacity is expanding faster than many consortium review processes. Generating
