Section 508 for reports, charts and data files

The report is electronic content too

Most conversations about Section 508 are about websites and software. Most of what a research or analysis contract actually delivers is documents: a final report as a PDF, a slide deck, a technical appendix, a workbook of tables, a set of CSV files with a data dictionary. Those are electronic content under the Revised 508 Standards, and an agency that publishes them or uses them for official communication must make them accessible. A report that a screen reader user cannot follow, or a chart whose meaning lives only in its colors, is a deliverable the agency often cannot accept as delivered.

The work is not hard, but it has to happen in the right place. Nearly every accessibility failure in a report was created upstream, in the word processor, the charting script or the spreadsheet, and then frozen into a PDF where it is tedious to fix. Teams that build accessibility into the source files ship clean deliverables at almost no extra cost. Teams that remediate at the end pay for it on every revision.

What the standard asks of a document

The Revised 508 Standards incorporate the Web Content Accessibility Guidelines, WCAG 2.0, at Level A and Level AA by reference, and apply them to electronic documents as well as web pages. For a document, that translates into a set of concrete requirements: text alternatives for images and charts, structure that software can read, a logical reading order, real table headers, sufficient color contrast, information that does not depend on color alone, a document title and a declared language.

Two numbers come up constantly. Normal text needs a contrast ratio of at least 4.5 to 1 against its background. Large text, meaning at least 18 point or 14 point bold, needs at least 3 to 1. Those apply to text in charts, axis labels, legends and table cells as much as to body paragraphs.

Start in the source file, not the PDF

A PDF's accessibility is mostly inherited from the file it was made from. Use the word processor's built-in heading styles for every heading, in order, without skipping levels. Use real lists rather than typed hyphens. Build tables with the table tool and mark the header row. Add alt text to every image and chart in the source. Set the document title and language in the file properties.

Then export with the option that preserves tags and structure. Printing to PDF usually discards the structure entirely and produces a file that looks identical and reads as one undifferentiated block to assistive technology. That single choice, export rather than print, separates many passing reports from failing ones.

Templates pay for themselves. A report template with the styles, the title page, the table formats and the chart color palette already set up and checked means every report starts accessible. When several analysts contribute sections, the template is what keeps the structure consistent.

Tagged PDFs and reading order

A tagged PDF carries a hidden structure tree that tells assistive technology what each element is: heading, paragraph, list, table, figure. A screen reader uses the tags to announce structure and to let the user jump between headings. Without tags, the user hears a stream of text with no landmarks.

Reading order is the sequence in which that structure is read. In a simple single-column report it usually follows the page. It goes wrong with multi-column layouts, sidebars, callout boxes, figure captions placed beside figures, and footnotes. A screen reader user should hear a callout box after the paragraph it relates to, not in the middle of a sentence, and a caption next to its figure, not at the end of the page.

Check it with the reading order and tags tools in a full PDF editor and with a dedicated PDF accessibility checker. Then do the test that catches what checkers miss: open the file in a screen reader and listen to the first few pages and one complicated page. If the order sounds wrong, it is wrong.

Alt text that states what the chart shows

The most common chart failure is alt text that names the chart instead of describing it. "Figure 3" or "Bar chart of uptake by county" tells the reader that a chart exists. It does not tell them what the chart says, which is the only reason it is in the report.

Alt text for a chart should say what a sighted reader would take away from it, not what kind of chart it is. Write the alt text as the finding. Consider an illustrative chart of vaccine uptake by county. Weak alt text: "Bar chart showing uptake rates." Useful alt text: "Uptake ranges from about 40 percent to about 75 percent across the twelve counties; the three rural counties are the lowest." The second version gives a screen reader user the same takeaway a sighted reader gets in a glance.

Keep alt text short, a sentence or two, and put the full data somewhere accessible: a data table immediately after the chart, in an appendix, or in an accompanying data file, with the alt text pointing to it. Complex charts such as maps, flow diagrams and multi-panel figures usually need a longer text description in the body or an appendix, with the alt text summarizing and referring to it. Purely decorative images should be marked as decorative so assistive technology skips them.

Charts that work without color

WCAG 2.0 requires that color not be the only means of conveying information. A line chart where the only way to tell the treatment group from the control group is that one line is blue and the other orange fails for readers with color vision deficiency, on a grayscale printout, and on a low-quality projector.

• Label directly. Put series names at the end of each line or on each bar instead of relying on a color legend.
• Add a second cue. Vary line style, marker shape or fill pattern along with color.
• Check text contrast. Axis labels, tick labels, data labels and legend text must meet 4.5 to 1, or 3 to 1 if large.
• Mind light colors. Pale yellow, light gray and pastel fills on white are where contrast usually fails.
• Test in grayscale. If the chart is unreadable in grayscale, it relies on color alone.
• Keep text as text where you can. Titles and notes typed in the document rather than baked into the image are readable, searchable and scalable.

Build these rules into the charting code or the template once, rather than fixing charts one at a time. A shared palette with checked contrast and a default of direct labels turns compliance into the default output.

Data tables with real header cells

A data table is accessible when software knows which cells are headers and which data cell belongs to which header. A screen reader can then announce something like "County: Adams, Uptake: 62 percent" for an illustrative row instead of reading a row of numbers with no context.

Mark the header row, and the header column if the first column labels rows. Keep tables simple: one header row where possible, no merged cells in the body, no empty cells used for spacing, and no tables used only for layout. When a table spans pages, set the header row to repeat. Give each table a caption or title that says what it holds.

Complex tables with multiple header levels can be made accessible, but they take careful tagging and they are hard to read for everyone. Often the better fix is to split one complex table into two simple ones.

Spreadsheets and CSV files

Workbooks and data files are where research deliverables most often slip through, because nobody thinks of them as documents. They are, and they have their own accessibility patterns.

Spreadsheets. Give every sheet a meaningful name and delete empty sheets. Start each table at the top left with a single header row. Avoid merged cells, blank rows and columns used for spacing, and color used as the only way to flag a value; add a text column instead. Put notes and sources in a dedicated notes sheet or in clearly labeled cells above or below the table rather than in floating text boxes. Add alt text to embedded charts and set the workbook title in its properties. Run the built-in accessibility checker before delivery.

CSV files. A CSV is plain text, so it has no formatting to get wrong, and its accessibility rests entirely on structure and documentation. Use exactly one header row with clear, descriptive column names. Put no titles, notes or blank lines above the header and no totals or footnotes below the data. Code missing values consistently and say how. Use a standard encoding such as UTF-8. Deliver a data dictionary for every file, in an accessible format, that gives each column's name, plain-language definition, type, units and allowed values.

The data dictionary is what makes a CSV usable for someone who cannot glance at the data and infer what a column means. It is good practice for every reader and an accessibility requirement in spirit for anyone navigating the file with assistive technology.

HTML reports: automated checks, then a person

Many agencies publish reports as HTML pages, instead of or alongside PDFs. HTML is often the more accessible format, because browsers and screen readers handle it well, but only if it is built with real headings, lists, tables and labeled figures.

Test in two passes. First, run an automated checker over every page. Automated tools catch missing alt text, missing form labels, insufficient contrast, empty headings and missing page language quickly and reliably. They do not catch alt text that is present but useless, a reading order that is technically valid but confusing, or a chart that relies on color in a way the tool cannot see.

Second, have a person test with a keyboard only and with a screen reader. Tab through every interactive element and confirm focus is visible and the order makes sense. Then listen to the page in a screen reader, navigating by headings, and confirm that tables announce their headers and charts announce their findings. Record the tools, versions and results with the deliverable. That record is what lets the agency accept the work with confidence.

Where vendors usually fail

The same failures recur across vendors and agencies. Nearly all of them are cheap to prevent and expensive to fix after the fact.

Common failure	Why it fails	Fix
Scanned or image-only PDF	No text for assistive technology to read	Produce the PDF from the source file; if only a scan exists, run text recognition and then tag and verify it
Printed to PDF	Structure and tags are lost	Export with tags enabled from the source application
Alt text that only names the chart	The finding is unavailable to non-visual readers	Write the takeaway as alt text and provide the data table
Color-only legends	Series cannot be distinguished without color	Direct labels plus line style or marker shape
Low-contrast labels and pale fills	Text falls below 4.5 to 1	Checked palette in the charting template
Merged cells and multi-row headers	Header-to-cell relationships break	Simple tables with one header row; split complex tables

One more failure deserves its own line: remediating the final PDF instead of the source. When agency comments arrive and the report is regenerated, every hand fix in the PDF disappears, and the remediation starts over. Fix the source, regenerate, and re-check.

A checklist by deliverable type

Use the relevant list before every delivery, and keep the results with the deliverable.

Report or PDF

• Exported from the source with tags, title and language set in properties.
• Headings use styles in order, and lists and tables are real structures.
• Reading order checked with a checker and by listening in a screen reader.
• Every image has alt text or is marked decorative.

Charts and figures

• Alt text states the finding, with a data table or long description available.
• No information by color alone; direct labels or a second visual cue.
• All chart text meets contrast: 4.5 to 1, or 3 to 1 for large text.

Spreadsheets and CSV files

• One header row per table, no merged cells, no spacer rows or columns.
• Sheets named, notes in a notes sheet, workbook checker run.
• CSV has only header and data rows, consistent missing-value codes, standard encoding.
• Data dictionary delivered for every file in an accessible format.

HTML report

• Automated checker run on every page with issues resolved.
• Keyboard and screen reader test completed and recorded with tools and versions.

Frequently asked questions