Document intelligence selection Mark method for radio buttons

1. Yes, selection marks are supported and expected to work for checkboxes/radio-style elements

Selection marks (checkboxes, radio buttons, etc.) are a first-class concept in Azure AI Document Intelligence:

• The Layout API and custom models support selection marks as a distinct element type, alongside text and tables.
• Selection marks are detected with a state such as selected or unselected (for example, in the Layout API selectionMarks node, or as special characters in Content Understanding: ☒ / ☐).
• Custom template and custom neural extraction models both support selection marks as extractable fields.

So, for structured PDF forms, selection mark extraction is expected to work, provided the marks are visually clear and consistently rendered.

2. Label only the mark, not the surrounding text

For custom extraction models:

• Selection marks should be labeled by drawing the region around the checkbox/radio mark itself, not the label text next to it.
• The adjacent text (for example, “Indemnity type A”) should be treated as a separate text field if needed, not part of the selection mark region.

This aligns with how selection marks are treated in the platform: a selection mark is a visual glyph representing the state, separate from the text.

3. Recommended practices for training selection mark fields

Based on the documented behavior of selection marks and custom models:

• Use a custom neural model when possible
  • Custom neural models support structured, semi-structured, and unstructured documents and generally provide higher accuracy than template models, including for selection marks and overlapping fields.
  • If the language and scenario support custom neural, it is the recommended starting point.
• Ensure good visual quality and consistency
  • Use text-based PDFs or high-quality scans where the checkbox/radio glyph is clearly visible.
  • Avoid very faint, tiny, or irregular marks that differ significantly between samples.
• Provide representative training samples
  • Include documents where:
    • Different options are selected across samples (not always the same radio/checkbox).
    • Tables or repeated sections show selection marks in different rows/columns.
  • For complex tables or repeated sections, follow the general guidance for tagging complex tables: include samples with variations (single-page vs multi-page tables, etc.) so the model learns the layout patterns.
• Tag selection marks consistently
  • For each logical field (for example, indemnityType_A, indemnityType_B), draw a region around the corresponding checkbox/radio mark on each training document.
  • If a mark is not present or not applicable in a given document, mark it as not available in document/collection in the labeling tool, rather than forcing an incorrect region.
• Use the Layout/selectionMarks output to debug
  • Run the Layout model on sample documents to confirm that selection marks are being detected at all (and with the correct selected/unselected state) before or alongside custom training.
  • If Layout is not reliably detecting the marks, custom extraction will also struggle; in that case, improving document quality or mark design is necessary.

4. Fallback approaches if selection marks remain unreliable

If, after following the above practices, selection marks are still not reliable for some fields, the main fallback is to:

• Use Layout analysis with features=keyValuePairs or a custom extraction model to focus on the textual context instead of the mark itself.
  • For example, if the form has mutually exclusive options with clear text ("Indemnity type A", "Indemnity type B"), use the surrounding text and layout (tables, key-value pairs) to infer which option is selected.
• Treat the problem as a text/key-value extraction problem rather than a pure selection-mark problem:
  • If the form includes a textual indication (for example, a word or code next to the selected option), label and extract that text field instead of (or in addition to) the mark.
• As a last resort for very problematic marks, redesign the form (if under control) to use clearer checkboxes/radio buttons or explicit text fields that are easier for the OCR and layout engine to detect.

In summary:

• Selection marks are supported and expected to work for structured PDF forms.
• Label the mark only, not the label text, and use a custom neural model where possible.
• Provide varied, representative training samples and verify Layout’s selectionMarks detection as a baseline.
• If marks remain unreliable, fall back to extracting nearby text (key-value pairs, table cells) and using that as the source of truth for the option choice.

References:

• Which model should I choose?
• Document Intelligence custom models
• Document processing models
• Document analysis: Extract structured content
• Get started with the Document Intelligence Sample Labeling tool
• Tag fields