Matterhorn 23-001 · PDF/UA-1 UA1:7.13-1

Signature fields in an accessible PDF: what applies

Signature fields are widget annotations and are therefore covered by the form-field requirements in checkpoint 28.

What a screen reader actually does

An unlabelled signature field is announced as an anonymous form control.

What the protocol says, and what follows from it

Checkpoint 23 has one entry, and it is a pointer rather than a test: nothing specific to digital signatures is required, but other provisions apply — the form-field ones. The protocol also points to 01-006, structure types that are not semantically appropriate.

The reason is that a signature field is a form field like any other. It is a widget annotation with field type /Sig:

50 0 obj
<< /Type /Annot /Subtype /Widget
   /FT /Sig  /T (Signature1)
   /TU (Applicant's signature)            % accessible name      → 28-005
   /Rect [ 72 600 272 640 ]
   /StructParent 4                        % its <Form> element    → 28-010
   /V 51 0 R                              % present once signed
>>

51 0 obj
<< /Type /Sig /Filter /Adobe.PPKLite /SubFilter /adbe.pkcs7.detached
   /ByteRange [ 0 18200 34586 1414 ]      % the bytes the signature covers
   /Contents <3082…>                      % the signature itself
>>

So the conditions that apply are the ones for any field: an accessible name, from /TU or alternate text on its element (28-005); a place in the structure tree inside a <Form> element (28-010); and a page tab order that follows the structure (28-008, 28-009). If the field has a script that runs on signing, the script conditions apply to it as well — Acrobat’s signature field properties include one (Adobe: Field specific properties).

Sign last

The part of signatures that does matter for accessibility work is the order of operations.

A signature covers the bytes of the file as they were when it was signed — /ByteRange above lists them. Tagging a field, writing its tooltip or setting tab order afterwards changes the file. Either the change is appended as an incremental update, leaving the signed bytes intact but giving signature validation a change after signing to report — and a certified document can forbid exactly that kind of change — or the file is rewritten, and the signature no longer matches anything.

So an accessible signed form is made in one order: build and remediate the unsigned form — accessible PDF forms covers the fields themselves — check it, then sign it.

How to check it free

List the signature fields. This prints each one with its tooltip and whether it has been signed, using Python and the free pikepdf library:

import sys, pikepdf

def fields(kids):
    for f in kids:
        yield f
        yield from fields(f.get("/Kids", []))

pdf = pikepdf.open(sys.argv[1])
for f in fields(pdf.Root.get("/AcroForm", {}).get("/Fields", [])):
    if f.get("/FT") == "/Sig":
        print(f.get("/T"), "| tooltip:", f.get("/TU"),
              "| signed" if "/V" in f else "| not signed")

A tooltip of None fails 28-005 unless the field’s tag carries alternate text; one that only repeats the field’s name passes it and still tells the reader nothing.

In Acrobat Pro, the Accessibility Checker covers the field under its Forms rules — Tagged form fields and Field descriptions — and its Tab order rule (Adobe: Create and verify PDF accessibility).

How to fix it free

All in Acrobat Pro, before anyone signs:

• Tooltip. Double-click the field to open its Properties, and on the General tab type into the tooltip box (Adobe: Manage form field properties).
• Tagging. Adobe’s fix for untagged fields is All tools → Prepare for accessibility → Automatically tag PDF. For a single field in an otherwise tagged document, the Tags panel’s Find command searches for unmarked annotations and can tag what it finds (Adobe: Edit document structure with the Content and Tags panels).
• Tab order. In the Page Thumbnails panel, select a page, choose Page Properties from the Options menu, then Tab Order → Use Document Structure, for each page with fields; or let the checker’s Fix do it for the Tab order rule.

Then sign.

What Taggart does

Taggart has no check called 23-001 — there is nothing for one to test — but it holds signature fields to the form-field conditions, which is what the protocol asks. On a generated file with an unsigned field named Signature1, no tooltip, no structure and no tab order, it reported 28-005 naming the field and its type ('Signature1' (/Sig)), 28-008 and 28-010.

The structure and tab-order repairs are safe ones that Fix All Safe applies: the field goes into a <Form> element and the page gets structure tab order. The tooltip is a decision. Given text for the field, the form-field-tooltips fix writes it and 28-005 clears; on that file, all three findings were gone afterwards. In the application, though, that fix is offered as Derive form field names from the field names, and for a field called Signature1 that produces the tooltip Signature1 — flagged in the change log for review, and worth replacing with whose signature it is. The app does not yet take the text per field; write it as the field’s tooltip in Acrobat, or in the program that made the form, and check the file again.

One thing to know before using Taggart on a signed file: it writes a new file rather than appending an update, so a signature made before remediation will not survive it. Taggart says so before the repair runs, and the repair’s change log names each signature it invalidated — the field, who signed and when — and says the repaired copy must be signed again; a certified file is told it must be certified again by its author. Remediate the unsigned form, then sign the output.

How Taggart handles it

The protocol defines no specific test for this condition, so there is nothing to check.

Where this sits in the standards

Related conditions

• 28-005 A form field has neither a TU entry nor an alternative descriptionThe /TU tooltip is the accessible name of a PDF form field. Without it the field has no name at all — the visible label printed next to it is not connected to the control.
• 28-010 A widget annotation is not nested within a Form tagEvery form control must sit inside a Form structure element.
• 28-008 A page containing an annotation does not contain a Tabs entryAny page carrying annotations must declare a tab order. PDF/UA-1 requires /Tabs /S — tab order follows the structure tree.
• 01-006 Structure type is not semantically appropriateThe tag does not match the nature of the content: a heading tagged as a paragraph, a data table tagged as a layout container, a caption tagged as body text. This is the judgment call that no validator can make for you.

Other conditions in checkpoint 23

Checkpoint 23 covers digital signatures. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

This condition needs a person’s judgement, so there was nothing for a tool to check. Written from ISO 14289-1 and the Matterhorn Protocol on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-10.