Accessible Documents: Invoices and Data Sheets

Since 28 June 2025 the German Accessibility Strengthening Act has applied to products newly placed on the market and to services in electronic commerce (BFSG). In most projects, implementation stops at the edge of the browser window: the shop is tested, contrasts are corrected, keyboard operation is retrofitted. The PDF invoice in the confirmation email, the data sheet attached to the product and the user manual in the download area stay exactly as they were. Those documents are covered as well, and that is where the blind spot of accessibility work sits in practice.

Why the obligation does not stop at the browser window

Under section 1 paragraph 2 the act covers products placed on the market after 28 June 2025 (BFSG), plus a range of services that includes trade in electronic commerce. Section 3 paragraph 1 defines accessible as findable, reachable and usable for people with disabilities in the customary manner, without particular difficulty and in principle without outside help (BFSG). That wording contains no exception for attachments. Anyone who accepts an order and sends the invoice as a PDF is providing the service not only in the browser but also in that attachment. Our article on implementing the BFSG in retail sets out the basic duties and their deadlines.

The size of the affected group is regularly underestimated. At the end of 2025 a good 7.8 million people with a severe disability were living in Germany (Statistisches Bundesamt). That was 9.4 percent of the population (Statistisches Bundesamt). Among 4 percent of those people, blindness or a visual impairment was recorded (Statistisches Bundesamt). Added to that are people with motor and cognitive impairments and a growing number of older customers who work with enlarged type. For this group, the document decides whether an order stays comprehensible or whether the invoice total is read out before it is clear what it belongs to.

The duty becomes concrete in the ordinance to the act. Section 12 number 2 requires, among other things, that the information content be made available in text formats suitable for generating alternative assistive formats by the consumer (BFSGV). Letter f explicitly names typeface, font size, contrast and spacing (BFSGV). Letter g requires an alternative presentation of the content where elements of non-textual content are included (BFSGV). Letter h sums it up: the digital information required to provide the service must be made available in a perceivable, operable, understandable and robust way (BFSGV). An invoice is digital information required to provide the service. So is a data sheet that carries the purchase decision.

The review matrix: document type versus requirement

Not every requirement hits every document equally hard. An invoice typically contains a logo, a table of line items and running text with payment terms. A user manual contains figures, warnings and cross-references between chapters. A fillable complaints form additionally contains input fields. Anyone who works through all files with the same checklist loses time on requirements that do not apply in the individual case and overlooks the ones that do. The matrix below maps the five requirements that matter most in practice onto the document types a shop produces.

The columns are not a house opinion but the WCAG success criteria in the form that clause 10 of the standard transfers onto documents (ETSI). Anyone who draws up this mapping once for their own document inventory has the review plan for every template change that follows. Which criteria were added with version 2.2 and what of that carries over to documents is set out in our article on the new WCAG 2.2 success criteria. The practical value of the matrix is that it moves the discussion from the format to the content: the PDF is not the problem, the PDF without structure is.

Tagging: the invisible structure inside the PDF

A PDF initially records only which character sits at which position on the page in which typeface. To the eye that produces a heading, a table and a footer. To a screen reader it produces an unordered set of text fragments. The bridge between the two is the tag tree: a second, invisible layer in the document that records that a line is a heading, that a block is a table with a header row and that a graphic is decorative or carries content. Clause 10 transfers the success criterion on information and relationships onto documents (ETSI): structure and relationships conveyed visually must be programmatically determinable.

• Headings need a level, not a larger font. A bold line without a tag is just another paragraph to speech output.
• Tables need marked-up header cells. Without them, speech output reads the line item table of an invoice as one long chain of numbers with no reference to the column.
• Lists need list tags. Payment terms set as paragraphs with a leading hyphen lose their connection when read aloud.
• Decorative elements need to be marked as artifacts. Rules, watermarks and background areas do not belong in the reading flow.
• Page headers and footers belong marked as artifacts too, otherwise speech output repeats the postal address on every page.

Tagging rarely happens by hand. It happens in the generator. If the invoice template is produced from a word processor or from a template language in the shop, the markup there decides whether a tag tree ends up in the PDF. That is exactly why the change belongs to template development rather than to a downstream tool. A document tagged after the fact has to be reworked with every template change. A generator that tags cleanly delivers the structure on every run.

Reading order: when the invoice is read out sideways

The second layer next to the tag tree is order. Success criterion 1.3.2 requires that a correct reading sequence can be programmatically determined where the sequence in which content is presented affects its meaning (W3C). Clause 10.1.3.2 transfers exactly this criterion onto documents that are not web pages (ETSI). In practice it breaks on multi-column layouts: an invoice with the sender block on the left, the recipient block on the right and the line item table below is read out in the order in which the blocks sit in the document, not in the order the eye takes them in.

The most common feedback from user tests with speech output is not that something is missing. It is that the order does not match the meaning.

XICTRON development team

The check is inexpensive and needs no external system: the document is converted into a plain text version and the resulting order is read. If the invoice total comes before the line item table, if the footer appears in the middle of the payment note or if the customer number only turns up after the payment terms, the order is wrong. Another candidate is the document title. Clause 10.2.4.2 requires a title that describes the topic or purpose of the document (ETSI). The file name alone is not enough; the title property inside the document has to be filled, otherwise speech output announces a string made of order number and timestamp. Why tools that try to paper over such deficits from the outside shift the problem rather than solve it is described in our article on accessibility overlay widgets.

Text alternatives inside documents

Success criterion 1.1.1 requires a text alternative for non-text content that serves the equivalent purpose (W3C). On the web this is the second most frequently measured defect after contrast: on 53.1 percent of the home pages examined, alternative text for images was missing (WebAIM). There is no reason to assume the rate is better inside documents, because there the habit of even asking the question is missing as well. In an invoice the typical candidates are few, which is precisely why a fixed rule per image type pays off more than a case-by-case decision.

• Company logo: the alternative text is the company name, not a description of the mark.
• Barcode or matrix code: the alternative text is the encoded value in plain text, for example the tracking number.
• Signature graphic: the alternative text names the signing role, not the lettering.
• Chart in a data sheet: the alternative text states the message; the value table belongs in the document as a tagged table alongside it.
• Rules, colour areas, watermarks: no alternative text, but marking as an artifact.
• Warning symbol in a manual: the alternative text names the warning level, because colour alone does not carry the meaning.

Alternative texts for product images follow the same logic as in the shop, except that in a document they have to be passed from the data model into the template. How to maintain and check those texts in the product data inventory is described in our article on alternative text for product images. The distinction matters: an alternative text that describes the picture is rarely helpful. An alternative text that describes the function of the picture in that place is reusable as a rule.

Form fields in fillable PDFs

As soon as a document contains input fields, another layer is added. Success criterion 3.3.2 requires labels or instructions where content requires user input (W3C). Clause 10.3.3.2 transfers that onto documents (ETSI). On the web this labelling is missing surprisingly often: missing form input labels were measured on 51 percent of the home pages examined (WebAIM). In a complaints or withdrawal form delivered as a PDF the defect weighs more heavily, because there is no second input route beside it.

1. Every field gets a unique name and a visible label that is programmatically associated with the field.
2. Mandatory fields are marked as such, not merely furnished with an asterisk.
3. The tab order follows the reading order; if focus jumps from the address into the signature line and back, the order is set wrong.
4. Error messages and format hints sit as text in the document, not as an explanation in a marginal graphic.
5. Groups of related fields get a shared label so that speech output announces the relationship.
6. Focus stays visible; a field without a recognisable focus outline is hard to operate by keyboard.

Requirements like these belong in the tender, not in the acceptance test. Anyone who formulates them only during testing is negotiating change requests. How to write document requirements cleanly into a requirements specification for a shop project is shown in this week's article on the subject. As a rule of thumb it has proved useful to name one sample document per document type as the object of acceptance instead of phrasing the requirement in the abstract.

Language marking: German, English, product name

Clause 10.3.1.1 requires that the default human language of a document can be programmatically determined (ETSI). This is the setting that decides pronunciation: speech output that reads a German document with an English voice turns an invoice into a puzzle. The corresponding principle in the success criteria requires the same for every web page (W3C). How often the declaration is missing is shown by measurement on the web: on 13.5 percent of the home pages examined the document language was missing (WebAIM). In documents the rate is typically higher, because many generators take the language from the server settings.

What invoice dispatch makes of it

In practice document accessibility rarely fails on intent and frequently on the route. Several stations sit between shop and mailbox, and each of them can lose the structure. The shop generates an invoice, the ERP system generates a second one, the shipping provider adds a third. If the document is printed and scanned again along the way, the tag tree is gone and an image remains. If documents are merged, the result is a combined PDF whose reading order nobody has set. If it is signed, a layer is added that leads some generators to rewrite the document.

Structured invoice exchange helps here more than many expect. A hybrid invoice format places the machine-readable data as an attachment inside the PDF; that embedded data structure is in itself already a text format within the meaning of section 12 number 2 letter e (BFSGV), because alternative presentations can be generated from it. The visual component still has to be reviewed, because it is what most recipients open. How to wire up both sides cleanly in a shop is described on our page on ZUGFeRD and XRechnung and in our article on e-invoicing obligations in retail.

• The visual component of the invoice carries a tag tree and a filled document title.
• The line item table has marked-up header cells and a reviewed reading order.
• Cancellation documents and credit notes use the same template as the invoice, so the structure holds beyond the standard case.
• The dispatch route does not turn the tagged document into a raster image.
• Combined PDFs made of several documents keep their structure and title per document.
• The language declaration in the document comes from the order, not from the server environment.

The third point of the list is often overlooked. In many shops, cancellation documents and credit notes come from a separate template that grew historically and only rarely took the same route through quality assurance as the invoice. The special cases involved are described in our article on cancellation invoices and credit notes. It pays to extend the review scope to those secondary documents deliberately, because in a dispute they carry the same evidential weight as the main invoice.

Data sheets, manuals and the rest of the library

Invoices are generated automatically and can therefore be repaired in one place. Data sheets, declarations of conformity and user manuals, by contrast, mostly come from the manufacturer and sit as finished files in the download area. This raises the question of responsibility. The answer is uncomfortable: anyone who makes the file available for download in their own shop is providing information for their own service and falls under section 12 number 2 letter h (BFSGV). A reference to the manufacturer changes little. In practice this leads to three routes that can be combined: oblige the manufacturer to supply accessible files in the supplier agreement, additionally carry the core information as a tagged version in the shop, or rework the document in house.

There is more than the legal position in favour of the second route. Core information held as structured text in the shop is also usable for search, for comparison and for internal linking. The document remains available alongside it but loses its role as the sole carrier of the information. With very large inventories, prioritising by revenue and download frequency makes more sense than a blanket effort: the twenty most frequently retrieved manuals typically cover a substantial share of actual use. Whether a microenterprise is exempt from the obligations is worth a separate check; our article on exemptions for microenterprises describes where the line runs.

A route to a reviewable document chain

The third point decides how long the result lasts. An invoice template repaired once rarely stays unchanged: a new logo, an additional mandatory disclosure or an adjustment to the footer is enough to damage the tag tree. An automated run that generates a sample document after every template change and checks its structure against a target specification costs effort once and nothing afterwards. How such runs fit into a test suite is described in this week's article on end-to-end test automation. For assessing the inventory the order is the same as in the front end: measure first, then prioritise, then rebuild.