On the large screen the table looks neat. Three rows, four columns and a coloured bar seemingly suffice to explain the offer comparison. When read cell by cell, however, it only says “1.200” with no discernible indication of which property, period and attribute the value belongs to.
This workshop is aimed at editorial teams and real-estate companies in Austria and Germany. It deals with a self-designed public data table. The example data are fictitious. No specific portal is examined nor is full accessibility or national legal compliance certified.
Which question justifies the table grid?
In the model readers are to compare three fictitious offers by their stated monthly costs. A table is helpful for this when each row refers to the same reference object and each column to the same attribute. A side-by-side set of different types of prices would, despite neat lines, not be a clean comparison.
The editorial team first spells out the readers’ question. It then decides which details need to be placed side by side. Not every detail from a large working file must appear in the public table. More columns can obscure the context if they do not serve the question.
The type of value is also determined: confirmed offer figure, own example calculation or still open question. These states are not distinguished solely by a colour. In the example an unknown value receives an understandable label instead of an arbitrary zero.
Be able to reconstruct the meaning of each data cell
The WAI guidance describes a technical mapping of header and data cells for data tables. Assistive technologies can thereby convey the appropriate context when navigating. Visual emphasis of headings alone is not sufficient for an accessible table. [TABLE]
For your own design this means: name rows and columns so that their relationship remains clear. In the example a column header is not just “Costs” but denotes the actually represented monthly total and its unit. The row has a unique fictitious offer identifier.
The editorial team does not merely hand over a screenshot. It describes which heading belongs to which cells. The responsible technical implementation chooses a suitable markup for this. This article does not provide a universal code that correctly solves every possible table structure.
Explain the topic beyond individual cells
A brief table title can convey what it is about overall. For an unusual or complex layout additional orientation may help. The WAI guidance distinguishes these functions and explains that a summary should not simply repeat the title. [CAPTION]
In our simple example the title could state the comparison subject and its fictitious nature. A short accompanying text then explains which cost items are included and why the values do not represent complete real household budgets.
This is different from a meaningless heading such as “Overview”. Readers should be able to recognise whether the table helps with their question. If the same layout is later used with other data, the title, units and explanation must fit the new content.
Do not only scale down complexity
The first model also contains several row headers, combined intermediate headings and nested monthly sections. The editorial team asks whether all the relationships really need to be in a single table. Perhaps two clearly separated presentations are more comprehensible if they answer different questions.
A split must not, however, hide a necessary relationship. Whoever is to compare two values must still be able to recognise their relation. The decision is therefore not based solely on a narrow screenshot but on the intended reading task.
If a larger table is retained, its actual structure must be expressly included in the technical brief. The appropriate solution depends on the layout. The information must not simply be shrunk to a tiny image and then called accessible.
Check the final output, not just the draft
When converting from one editing format to another structural table information can be lost; the WAI guidance points this out. [TABLE] Therefore check the actual intended output format. A well-structured working file does not automatically guarantee the later web export or the PDF.
Our own editorial test begins with a single cell: can the person carrying out the check form the complete sentence about it? For example: “For the fictitious offerA this value denotes the stated monthly amount in euros.” If the assignment remains unclear, the concrete cause is noted.
A technical acceptance must also test the actual accessible relationships and interactions. The mere appearance on one’s own monitor does not replace it. Even one successful single test does not confirm every possible usage situation.
The result of the workshop is a limited, comprehensible data presentation with a stated topic, unambiguous units and traceable relations. Readers should be able to answer their comparison question. A perfect grid without recognisable meaning would merely be a carefully formatted information gap.