When I talk to companies about digital accessibility, the conversation almost always starts with the website. Documents come later, and usually in a whole pile: statements, forms, presentations and spreadsheets that have been created over the years in Word, PowerPoint and Excel and are sent out as PDFs or uploaded to the website.<\/p>\n\n
In this guide, I\u2019ll show you where accessible documents are actually created: not just when you export them as PDFs, but right from the source file. You\u2019ll learn which habits end up causing the most work later on, how to set up Word, PowerPoint and Excel properly, how to recognise a good template, and where automatic checking reaches its limits.<\/p>\n\n
In a nutshell: accessible documents in six steps<\/strong><\/p>\n\n A document may look neat and tidy, yet still be unusable for many people. A screen reader does not read out the layout, but rather the underlying structure. A line that is simply set in large, bold type may look like a heading, but to a screen reader it is just normal text. Someone who is blind and navigating a twenty-page document jumps from heading to heading. If these headings are missing, the only option is to listen to the whole document from start to finish.<\/p>\n\n Accessible documents are therefore designed in such a way that their structure and content remain understandable even without visual input: headings are marked as headings, tables have headings, images have alternative text, and the reading order is correct. This benefits not only people who use a screen reader, but also those with visual impairments who use high magnification, and anyone who wants to skim through a document quickly.<\/p>\n\n There is one distinction I think is important here: \u2018low-barrier\u2019 and \u2018barrier-free\u2019 are not the same thing. A document processed automatically breaks down barriers and is therefore \u2018low-barrier\u2019. It is only \u2018barrier-free\u2019 once a person has checked it, for example using a screen reader. This is because no software can reliably determine whether alternative text truly explains a diagram or whether the reading order makes sense.<\/p>\n\n This depends heavily on the sector and the individual company. For our clients, these are usually customer statements \u2013 in other words, administrative documents. They are produced in large numbers, sent directly to customers and contain precisely the information that everyone needs to understand: amounts, deadlines and contract details.<\/p>\n\n Depending on the organisation, other areas may also be involved, such as presentations and brochures from the marketing department, or forms and job advertisements from the HR department. My advice: decide who within the organisation is responsible for the digital accessibility of documents. As long as each department deals with this on its own, every document will be produced according to its own set of rules.<\/p>\n\n For public bodies, this is a mandatory requirement in any case: the BITV 2.0 explicitly applies to documents published since 23 September 2018. Organisations covered by the Accessibility Enhancement Act (BFSG) should also take into account documents that customers receive as part of the services they provide.<\/p>\n\n The most costly habit is simply failing to take digital accessibility into account during the creation process. This means a document is first finalised and then has to be made accessible afterwards. Anyone who has ever inherited a template is familiar with the typical consequences:<\/p>\n\n Each of these shortcuts saves a few seconds during creation but ends up costing time later on for every single document. It is therefore best to integrate digital accessibility directly into the process: through properly set-up templates, a quick check before approval, and a team that knows what matters.<\/p>\n\n Use the appropriate style sheet for each heading \u2013 i.e. Heading 1 for the section title, Heading 2 for sub-sections, and so on \u2013 without skipping levels. Adjust the appearance in the style, not in the text. This also creates a table of contents automatically, and the navigation pane in Word shows you straight away whether the structure is correct.<\/p>\n\n Bulleted lists should be created using Word\u2019s list function, not by typing a hyphen. Tables should only be used for data, not for layout. Mark the first row as a header row, avoid merged and empty cells, and ensure the header row is repeated on every page for long tables. Spacing is created using paragraph spacing; page breaks are created using a page break, not by inserting multiple blank lines.<\/p>\n\n Every image containing information requires alternative text, which you can add via the image\u2019s context menu. For a diagram, this should describe the message, not the visual appearance. Mark purely decorative images as \u2018decorative\u2019 so that screen readers skip them. It is best to position images \u2018in line with text\u2019 so that they appear in the correct place in the reading order. I explain in detail how to write good alternative texts in the guide \u2018Writing Alt Texts<\/a>\u2019.<\/p>\n\n A link should indicate where it leads: \u2018Application for payment by instalments\u2019 rather than \u2018click here\u2019 or a long address. Set the document language correctly and mark passages in foreign languages so that the screen reader changes the pronunciation. Enter a meaningful title in the document properties. This is the first thing that is read aloud when the document is opened.<\/p>\n\n Practical tip: In Microsoft 365, Word, PowerPoint and Excel include their own accessibility checks. These identify missing alternative text, tables without headers or poor contrast, and are a good first step before any document is finalised. However, they do not tell you whether the document is understandable to a human reader.<\/p>\n\n In presentations, the problem usually lies in elements placed randomly. What looks logical on the slide is read out by a screen reader in the order in which the objects were created. Here\u2019s what you should bear in mind:<\/p>\n\n Practical tip<\/strong>: Access Read<\/a> checks whether your PDFs meet the machine-verifiable requirements of PDF\/UA free of charge and without the need to register, with up to five files per check. Access Doc<\/a> then formats any issues identified by the check to make them accessible.<\/p>\n\n To a screen reader, an Excel file is simply an area made up of cells. For it to make sense, it needs some context:<\/p>\n\n We can tell from the document structure. We do not work within our clients\u2019 systems, but through our interactions with them \u2013 particularly in support \u2013 it quickly becomes apparent how a team works. Where templates are set up properly, documents consistently feature proper headings, proper lists and tables with headers. Where every document has been formatted manually, each one looks slightly different, and each one requires its own reworking.<\/p>\n\n This is where the greatest benefit lies: once a template has been set up correctly, its structure is passed on to every document created from it. Anyone who produces hundreds of statements or letters each month can resolve this issue in one place rather than in each document individually.<\/p>\n\n Most documents leave the company as PDFs. To ensure that the structure from Word is retained, use \u2018Save As\u2019 or \u2018Export\u2019 to save as a PDF and enable the document structure tags for accessibility in the options. Using \u2018Print as PDF\u2019 causes this structure to be lost. I explain what else needs to be checked in the PDF afterwards in the guide \u2018Creating accessible PDFs<\/a>\u2019.<\/p>\n\n There\u2019s one thing you should bear in mind: automatic conversion is never 100 per cent accessible. It produces a document with minimal barriers. To ensure a document is fully accessible, it needs to be checked by a human, for example using a screen reader.<\/p>\n\n Yes. We always design documents to be low-barrier or fully accessible; we have yet to come across a document where this isn\u2019t possible. With Access Doc, we systematically remove barriers in documents. If a 100 per cent accessible document or an accessible template is required, we can deliver that too.<\/p>\n\n There are, of course, special cases, particularly when it comes to colours. Many corporate identity schemes use light brand colours that do not provide sufficient contrast for text. The WCAG require a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. In such cases, it is worth working with the design team to find a solution that keeps the brand recognisable whilst still being legible for everyone \u2013 for example, using a darker shade of the brand colour for text, whilst retaining the light colour for background areas.<\/p>\n\n\n
What makes a document accessible<\/h2>\n\n
Where most documents are produced within companies<\/h2>\n\n
The habit that ends up creating the most work later on<\/h2>\n\n
\n
Accessible Word: how to set up documents correctly<\/h2>\n\n
Headings and style sheets<\/h3>\n\n
Lists, tables and spacing<\/h3>\n\n
Images, diagrams and alternative text<\/h3>\n\n
Links, language and document titles<\/h3>\n\n
Accessible PowerPoint: Slides that work when read aloud<\/h2>\n\n
\n
Accessible Excel: Tables that make sense<\/h2>\n\n
\n
How we can tell whether a team has set up its templates properly<\/h2>\n\n
From Office document to accessible PDF<\/h2>\n\n
Is this possible for every document?<\/h2>\n\n
Comparison: Approaches to accessible documents<\/h2>\n\n