Contract summaries, bills and tariff sheets as accessible PDFs

General orientation, not legal advice. How far the obligations reach for your organisation can only be judged case by case.

It starts with the contract summary

Article 102(1) of the European Electronic Communications Code (Directive (EU) 2018/1972) requires providers of publicly available communications services to give pre-contractual information in a clear and comprehensible manner on a durable medium. Where that is not feasible, an easily downloadable document will do. End-users with disabilities receive this information on request in an accessible format, in accordance with the Union law harmonising accessibility requirements. That means the EAA.

Article 102(3) adds a concise and easily readable contract summary. Among other things it states the provider and contact details, the main characteristics of the service, prices, duration and termination conditions, and the extent to which products and services are designed for end-users with disabilities. The template is laid down in Commission Implementing Regulation (EU) 2019/2243. Germany implemented the obligation in section 54 of its Telecommunications Act (TKG), Austria in its Telecommunications Act 2021. Under Article 111 of the Code, end-users with disabilities must have equivalent access to services and to contractual information.

The contract summary is almost always generated as a PDF, shown before the contract is concluded or sent by email. No other telecom document has accessibility anchored in law quite so clearly.

What a good contract summary looks like

The template fixes the sections and their order, which helps. Tag each section as a heading and the document structure is already done; screen reader users can then jump straight to "Price" or "Duration, renewal and termination". Beyond that:

• Prices, data allowances and bandwidths are text in the document, not graphics or icons. Footnotes on promotional prices are linked to the figure they belong to.
• The document title names product and provider ("Contract summary Mobile M, provider name"), and the document language is set.
• Text on table backgrounds and in brand colours reaches a contrast of at least 4.5:1 at normal text size.
• The section on features for end-users with disabilities contains actual information. A bare link to the website is not enough.

What the European Accessibility Act adds

Article 2(2)(a) of Directive (EU) 2019/882 covers electronic communications services provided to consumers after 28 June 2025. The only exception is transmission services used for machine-to-machine services. The directive takes the definition from Article 2(4) of the Code, which covers in particular internet access services, telephony and other interpersonal communications services. Germany's BFSG calls them "telecommunications services"; in Austria the BaFG applies.

For documents, the relevant part is Annex I Section III, which applies to every covered service. Information about how the service works must be perceivable and understandable and provided in text formats from which alternative formats can be generated. Adequate font size, sufficient contrast and alternatives for non-text content are required. That applies to PDFs directly.

What Annex I Section IV asks specifically of communications services has nothing to do with documents: real-time text alongside voice, total conversation where video is offered, and synchronised transmission of emergency communications. Answering emergency calls to 112 by public safety answering points is dealt with separately in Article 2(3). These are matters of network and service technology and are left aside here.

Document types and their weak points

Bills and itemised bills

For many customers the bill is the one document they actually open every month. It works with a screen reader when four things are right:

• Reading order: amount due, due date and payment method come early, not after the sender block, footer and promotional banner.
• Tables: line items and call records are data tables. Without TH header cells, users hear a string of numbers with no context.
• Page breaks: in multi-page records the table structure stays logical across pages; header rows repeated on following pages are artifacts.
• Fonts: billing generators often embed font subsets without Unicode mapping. The screen reader then reads amounts, euro signs or accented characters wrongly.

Nobody fixes millions of bills one at a time

Bills, reminders and contract documents run through output management systems in very large volumes. Fixing individual PDFs is not an option at that scale. Accessibility has to go into the output pipeline.

Many output management and composition systems can produce tagged PDF or PDF/UA as long as structure, reading order and tables are defined in the template. Ask your vendor specifically about this option. Testing then targets the template: a few documents per template in PAC and with a screen reader. Because the structure is identical in every copy, whatever is right in the template is right in the production run.

That leaves the risk of a software update or a template change quietly making things worse. Continuous automatic checks on outgoing documents through a REST API, covering tags, title, language, fonts and Unicode, catch that.

Older downloadable tariff sheets with no surviving source can be given a base structure through retroactive tagging. Tables and headings then have to be tagged by hand. Which WCAG criteria apply is covered in WCAG 2.2 for PDF documents.

Where telecom PDFs typically fail

Prices and data allowances as images. Font subsets without Unicode mapping, so the euro sign is read out wrongly. A section on features for people with disabilities that contains nothing but a link. And bill tables whose header row was never tagged as TH.

Part of this is caught by the EasyPDFUA check. It shows whether a structure tree exists, whether title, language and PDF/UA identifier are set, whether fonts are embedded and Unicode mappings complete, and whether links are tagged, in the browser or via the API with Premium. When tagging, EasyPDFUA adds title, language, a base structure, link tags and unambiguously derivable Unicode mappings. It does not create bill tables with header cells, a meaningful reading order in complex layouts or alternative text; those have to come from the template. A check report is not confirmation of legal compliance either.

The legal framework is described in The European Accessibility Act and PDFs; other sectors are listed in the overview of affected industries.

Frequently asked questions

Does the contract summary have to be accessible?

On request, yes. The Code requires pre-contractual information to be provided to end-users with disabilities in an accessible format on request, and since the EAA the general requirements for service information apply as well. We recommend generating the contract summary as an accessible PDF from the outset.

Does the EAA apply to machine-to-machine services?

No. Transmission services used for the provision of machine-to-machine services are explicitly excluded. The EAA covers electronic communications services provided to consumers.

How do I make millions of bills accessible?

In the output pipeline, not PDF by PDF. Templates in the output management system are built to be accessible, samples per template are tested manually, and ongoing production is checked automatically against basic requirements, for example via an API.

Can EasyPDFUA tag bill tables automatically?

No. EasyPDFUA checks bills and adds a base structure, title, language, link tags and unambiguous Unicode mappings. Header cells in bill tables have to come from the template or be set by hand.