Redaction appearance — redaction style, exemption codes, export enforcement, approval, and the accessibility check and accessible editions of packages
Last updated: October 20, 2026 by Steve
Redaction Appearance
Redaction appearance controls how redactions look and behave when a response package is produced: the final style on the released copy, how see-through redactions appear on the redline review copy, whether exemption codes are printed over each box, whether untagged redactions may block an export, whether unreviewed proposed redactions warn or block at export, and whether redactions must be approved before export, whether a package must pass the accessibility check before it is published or delivered, and when an accessible edition of a package is built.
Where to find it
Open the Settings hub and choose Redaction appearance, in the Documents & review group beside Exemptions.
Options
| Option | What it controls |
|---|---|
| Final redaction style | The appearance of applied redactions on the final release — the recipient's solid, opaque view |
| Redline transparency | How redactions render on the Redline review copy, so reviewers can read what is underneath (versus the opaque final) |
| Exemption-code overlay | Whether each redaction prints its exemption code on the box. Each mark can override this with its own Label — exemption, custom text, or none — and Set label applies a mode to several marks at once |
| Default region effect (recordings) | The effect a new region mark on a video starts with, and the effect face and on-screen text detections propose — Blur unless changed. See Video & Audio Records |
| Exemption-code enforcement | Whether untagged redactions block a Response export (Require), only warn with a Proceed anyway option (Warn), or are allowed (Off) |
| Proposed-redaction enforcement | Whether unreviewed proposed redactions (pattern, rule, AI, and prior-request suggestions awaiting accept/dismiss) warn at Response export — with a Review suggestions shortcut — or block it, enforced server-side until every proposed mark is accepted or dismissed |
| Alternate exemptions on the mark | Whether the overlay also prints the alternate exemptions a redaction cites: never, on redline copies only (the default), or always |
| Approval before export | Whether redactions must be approved before a package can be exported |
| Accessibility check before release | What the accessibility verdict on a response package does: Advisory (the default; the result is shown and never blocks), Require a pass, or an acknowledgement, before publishing to the reading room, or before any secure delivery or publication |
| Accessible edition of response packages | When an accessible edition is built beside a package: When it is needed (the default), For every response package that needs one, or Off |
How it affects end-user behavior
In the redaction workspace, coordinators tag each redaction with one or more exemption codes (which cite a legal authority); redactions are colour-coded by category, and a Redacted Preview simulates the recipient's solid-black view. On export from the Documents workspace:
- The Redline review export defaults to a translated "REVIEW COPY — NOT FOR RELEASE" watermark so it cannot be mistaken for a final release.
- If enforcement is set to Require, untagged redactions block the Response export; Warn instead offers Proceed anyway.
- If approval before export is on, redactions enter Pending approval and an Approver confirms them before a package can be produced. Administrators can reopen a locked redaction for re-disclosure.
Suggested redactions — whether from your rules and detection patterns or, when AI Assist is enabled, from AI redaction analysis — are only proposals. They flow through the same review pipeline as manual redactions: a coordinator accepts or dismisses each one, and when approval before export is on they are equally subject to the mandatory approval step before a package can be produced.
Accessibility check and accessible edition
Every response package is checked for accessibility when it is built, and its row in Export History carries an Accessibility chip: Passed, Needs review or Failed. The chip opens a report that lists what was found, failures first, and holds the human checks (confirming the reading order and the text alternatives).
- The accessibility checker. When your organization has deployed the accessibility checker, it checks the package in your own Azure subscription against the PDF/UA-1 standard and lists each file with the rules it fails and the pages concerned. Without the checker no package can pass, and AccessPoint never describes one as meeting PDF/UA-1. See the deployment guide.
- Release anyway. Someone who holds Release packages that did not pass the accessibility check can record why a package may be released although it did not pass. The reason is kept in the audit ledger, and the acknowledgement can be withdrawn. If you require the check, grant this permission to the people who may release packages that cannot pass.
- Rebuilding. Rebuilding a package clears its human-check confirmation and any acknowledgement, because it is a new file.
- Accessible edition. A redacted, scanned or untagged record cannot keep the tags a screen reader needs, so AccessPoint can build an accessible edition beside the package: each record is rebuilt as a tagged PDF with every redaction announced where it sits. The package itself is never changed. Once an edition is built, the accessibility check reads the edition. Editions need Azure AI Document Intelligence, which is billed per page read, so building only the editions that are used keeps that cost down; without it the edition is unavailable and such a package stays Failed.
- When it is built. With the default When it is needed, an edition is built at once when the request's Accessible format requested is set; otherwise when the package is delivered through the portal or proposed for the reading room, or when someone chooses Build accessible edition in the package's accessibility report.
See Response and export for how the chip and report appear to coordinators.
Tips
- Turn on approval before export where policy requires a mandatory second set of eyes before release.
- Use Require enforcement to prevent uncited redactions from ever shipping.
- Enable the exemption-code overlay when recipients expect the cited provision printed on each redaction.
- Where a redaction cites alternate exemptions, the overlay can print the fallbacks in parentheses (e.g.
s.19 (s.22, s.23)), collapsing to a count (s.19 (+2)) when they don't fit. This defaults to redline copies only, so the released copy stays clean.