Accessible Documents

What Makes a Document Accessible

A document is accessible when the information it carries is available to the software people use to read it, and not only to the eye. A sighted reader infers a great deal from appearance alone. Large bold text at the top of a section is understood as a heading. None of that meaning reaches a screen reader, a refreshable braille display, or a read-aloud tool unless it has been recorded in the file rather than merely suggested by the formatting.

Accessible authoring is therefore mostly a matter of telling the file what the visual design already tells the reader. When a heading is marked as a heading, a table has identified header cells, an image carries a description, and the order of the content is recorded correctly, the document that looks right also reads right. When those things are missing, a document can look perfectly professional and still be unusable.

Documents also differ from web pages in a way that matters here. A web page can be corrected once and every reader sees the correction; a document that has been sent exists in as many copies as there are recipients. That is the practical reason to get it right before it leaves the author's hands.

How WCAG Applies to Documents

The Web Content Accessibility Guidelines are written for web content. WCAG 2.2 is a World Wide Web Consortium Recommendation dated October 5, 2023, and its requirements are expressed as testable success criteria at three conformance levels. What the levels mean and how the versions relate to one another is covered in WCAG Overview rather than repeated here.

Documents are not web pages, so the World Wide Web Consortium publishes separate guidance on reading those same criteria in a non-web context. It is titled Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies, usually shortened to WCAG2ICT, and it is a W3C Group Note published on December 11, 2025, covering the Level A and Level AA success criteria of WCAG 2.0, 2.1, and 2.2. Its status matters: WCAG2ICT is informative guidance. It explains how the criteria can be understood when applied to documents and software, and it does not itself impose requirements.

Legal obligations are a separate question and depend on who you are and what you do. In United States federal technology standards, the Revised 508 Standards and 255 Guidelines, issued as a final rule on January 18, 2017, incorporate WCAG 2.0 Level A and Level AA by reference. That is WCAG 2.0, not a later version, and the difference is a common source of error. For how the guidelines, the Americans with Disabilities Act, and Section 508 relate, see WCAG vs ADA vs Section 508.

Public schools and other state and local government entities are separately subject to the Department of Justice's Title II rule for web and mobile accessibility, whose required technical standard is WCAG 2.1 Level A and Level AA. WCAG 2.2 is a newer W3C Recommendation, referenced on this page as a current best practice, and is not itself the Title II legal requirement.

Accessibility Belongs in the Source File

The decision that determines how much accessibility work a document will cost is where the work is done. Building structure into the source file, in the application where the document is written, is inexpensive and durable. Repairing a finished file afterward is expensive, easy to get wrong, and has to be repeated every time the document is revised.

Most documents are not written once; they are drafted, reviewed, amended, and reissued. A source file carrying real headings, tables, lists, and alternative text can be exported repeatedly, and each export inherits that structure. A file repaired after export loses the repair the moment someone regenerates it.

This is why accessible templates are worth more than accessible documents. An organization that fixes its letterhead, its report template, and its slide master once has changed the default for everything produced afterward.

Document Structure and Reading Order

Structure is the backbone of an accessible document. Headings should be applied using the application's built-in heading features rather than by enlarging and bolding ordinary text. Marked headings let a reader move through a long document by section and see an outline of it. Heading levels should reflect the actual hierarchy of the content rather than being chosen for visual effect.

Reading order is the sequence in which content is exposed to software, and it is not always the sequence a sighted reader perceives. Multiple columns, sidebars, captions, and floating images are all places where the recorded order can diverge from the order on the page. A document can look entirely conventional and be read aloud as an interleaved jumble.

A useful test needs no specialist tool: ask whether the document still makes sense when read straight through, with no visual layout at all. If a caption arrives before the thing it describes, the reading order needs attention.

Alternative Text

An image that carries information needs a text alternative that serves the same purpose. The alternative is read in place of the image, so it should convey what the image contributes at that point in the document rather than list everything it shows. A photograph of a building may need only the building's name; a diagram of a process may need the sequence of steps it depicts.

Images that carry no information, such as borders, background textures, and dividers, should be marked as decorative so that assistive technology passes over them. Describing decoration adds noise and makes the informative images harder to find.

Complex images need more than a short phrase. A chart, a map, or an organizational diagram rarely fits in a sentence, so its essential content should also appear in the body text or in an adjacent table, with the alternative text saying what the image is and where the detail can be found. A picture of text is a related failure: it cannot be searched, enlarged cleanly, or read aloud, and real text should replace it wherever possible.

Tables, Lists, and Link Text

A data table is usable without sight only if the file records which cells are headers. A screen reader user moving from cell to cell can hear each value together with its row and column headers; without that record the table becomes an unlabeled stream of numbers. Simple, regular tables with a single header row survive this far better than grids with merged cells, split cells, or tables placed inside other tables.

Lists should be built with the application's list features. A real list is announced as a list, often with its number of items, so a reader knows how much is coming. Lines that merely begin with a hyphen or a typed number are read as ordinary paragraphs.

Link text should say where a link goes. Many screen reader users scan a document by calling up a list of its links, hearing each one without its surrounding sentence, so phrases such as click here or more information tell them nothing. The name of the destination is almost always better link text than a pasted web address.

Color, Contrast, and Visual Formatting

Color can reinforce meaning but should never be its only carrier; WCAG 2.2 makes this a Level A success criterion. A table in which overdue items are marked only in red fails readers who cannot distinguish the color, and fails everyone once it is printed in grayscale. A word, a symbol, or an extra column resolves it.

Text also needs enough contrast with its background. At Level AA, WCAG 2.2 sets a minimum contrast ratio of 4.5 to 1 for text and 3 to 1 for large text. Pale gray body text, text over photographs, and light brand colors on small type are the usual failures.

Long passages in all capitals, in italics, or in very small type slow reading for many people, including magnification users. Where formatting carries meaning, such as bold marking a required step, the words should say so as well.

Document Language and Title

A document should record the language it is written in. Speech software relies on that setting to choose pronunciation, and a document marked with the wrong language can be nearly unintelligible when read aloud. Passages in a second language should be marked separately where the application supports it.

A document should also carry a real title in its properties, separate from its file name. Many applications can display that title when a document opens, and a descriptive title is far more useful than a file name built from abbreviations and version numbers. Where each format stores these settings is covered on the format pages.

Scanned Documents, OCR, and Forms

A scanned page is a photograph of a page. Until it is processed it holds no characters at all, so software has nothing to speak, search, or render in braille, and magnifying it enlarges the blur along with the letters. Scanning is still the usual way paper records and older publications enter digital circulation, which makes scanned files one of the most common barriers in practice.

Optical character recognition, usually shortened to OCR, turns the picture of text into characters. It is a necessary first step and an incomplete one. Recognition supplies the words and nothing more; the headings, table relationships, image descriptions, and reading order a reader relies on still have to be added, and recognition errors are easy to miss on screen. Where the original source file still exists, producing a fresh document from it is almost always the better route.

Forms raise their own questions. Every field needs a label that software can associate with it, the order in which fields are reached from the keyboard needs to match the visible order, and instructions and error messages need to be expressed in text rather than by position or color alone. A form that works only with a mouse, or only on paper, excludes people who could otherwise complete it independently.

Tagging, Conversion, and Export

Most documents are shared in a different format from the one they were written in, very often PDF, and the conversion step decides whether the work done in the source survives. Structure in a finished PDF is carried by tags, which record what each element is. Conversion routes that preserve structure carry headings, lists, tables, alternative text, and language into those tags. Routes designed only to reproduce appearance can discard all of it and leave a file that looks identical and reads as a flat run of text.

The export method is therefore an accessibility decision, not a clerical one. Organizations benefit from settling on a known-good export route for each application they use and writing it down, so that individual authors are not left to discover the difference on their own.

The mechanics differ by format. For what tags are and how a finished file is checked, see PDF Accessibility. For exporting from a word processor, see Word Document Accessibility, and for slide decks, see PowerPoint and Presentation Accessibility.

What Accessibility Checkers Can and Cannot Tell You

Most authoring applications include an accessibility checker, and running it every time is worthwhile. Checkers are good at finding faults that can be detected mechanically. Images without alternative text, tables without a header row, and missing document titles are typical examples, depending on the application.

What a checker cannot do is judge meaning. It can confirm that alternative text exists but not that it describes the right thing. It can confirm that headings are marked but not that they reflect the real organization of the content. It cannot tell whether a reading order makes sense, whether link text is informative, or whether a table is presenting data or merely arranging a page.

A clean result therefore means that one class of problems is absent. It is a starting point for review, not a statement of conformance. The rest is settled by a person reading the document through, ideally with the kind of assistive technology its readers are likely to use.

Requesting an Accessible Document

People who receive an inaccessible document are often unsure what to ask for. The most useful request is specific: identify the document, describe what cannot be done with it, such as reading a scanned letter with a screen reader, and say which format would work, whether a tagged PDF, a word processor file, plain text, large print, or braille.

For organizations, a request is information. It identifies a document failing at least one reader and, often, a template or export process failing many. Correcting the source file, rather than producing a single alternative copy, answers the request and the next ten like it. A clear contact route for format requests, named in the document itself, lets readers ask before they give up.

An alternative format provided on request is valuable, but it is not a substitute for publishing accessible documents in the first place. A reader who has to ask, wait, and follow up does not have the same access as a reader who can open the file when everyone else does.

Related AssistiveTechnology.org Resources

For the mechanics of individual formats, see PDF Accessibility, Word Document Accessibility, and PowerPoint and Presentation Accessibility. For what the guidelines are and how conformance levels work, see WCAG Overview. For how WCAG relates to United States law, see WCAG vs ADA vs Section 508. For documents in the workplace, see Digital Accessibility for Employers. For a general orientation to the subject, see Digital Accessibility, and for further reading across topics, see Resources.

Request accessibility services

Authoritative Sources

World Wide Web Consortium: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, for the success criteria referred to on this page.

World Wide Web Consortium, Web Accessibility Initiative: Understanding WCAG 2.2, informative explanations of the intent of each success criterion.

World Wide Web Consortium: Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT), W3C Group Note, informative guidance on applying WCAG 2 success criteria to documents and software.

U.S. Access Board: Revised 508 Standards and 255 Guidelines, including the incorporation of WCAG 2.0 Level A and Level AA by reference.

U.S. General Services Administration, federal Section 508 program: guidance on creating accessible documents, PDF files, presentations, and spreadsheets.

Last Standards Review

Last standards review: September 22, 2026. On that date the status and dates of WCAG 2.2 and WCAG2ICT, the conformance levels and contrast ratios of the WCAG 2.2 success criteria referred to on this page, and the incorporation of WCAG 2.0 Level A and Level AA by the Revised 508 Standards, with the date of their final rule, were verified against current World Wide Web Consortium and U.S. Access Board sources.

About This Page

This page provides general educational information about creating and requesting accessible documents. It is prepared by The Accessibility Clinic Inc. as educational information only. It is not legal advice, and it does not guarantee that any specific website, application, document, or product meets a particular standard or legal requirement. Organizations should evaluate their own obligations in light of their specific circumstances and consult qualified counsel when needed. Standards and regulations change; the last standards review date above indicates when the statements on this page were most recently verified against primary sources.