Pre-push review: T-1044 Reduce Transparency a11y

diff --git a/prism/Theme/AdaptiveMaterial.swift b/prism/Theme/AdaptiveMaterial.swiftnew file mode 100644index 0000000..ecf5f20--- /dev/null+++ b/prism/Theme/AdaptiveMaterial.swift@@ -0,0 +1,58 @@+import SwiftUI++/// Replaces a translucent `Material` background with an opaque `themeColors.surface1`+/// fill when the user has enabled Accessibility → Reduce Transparency.+///+/// Tracks accessibility audit finding H4 (Transit T-1044). See+/// `docs/accessibility-review.md` and `specs/reduce-transparency-a11y/smolspec.md`.+struct AdaptiveMaterialBackground<S: Shape>: ViewModifier {+    @Environment(\.accessibilityReduceTransparency) private var reduceTransparency+    @Environment(\.themeColors) private var colors++    let material: Material+    let shape: S++    @ViewBuilder+    func body(content: Content) -> some View {+        if reduceTransparency {+            content.background(colors.surface1, in: shape)+        } else {+            content.background(material, in: shape)+        }+    }+}++/// Suppresses `.glassEffect(.regular.interactive())` when Reduce Transparency is on,+/// returning the view unchanged. Every call site sits on `.buttonStyle(.bordered)`,+/// whose own opaque background is sufficient — painting a fallback colour underneath+/// would mean guessing the system's private shape for a bordered glass button.+struct AdaptiveGlassEffect: ViewModifier {+    @Environment(\.accessibilityReduceTransparency) private var reduceTransparency++    @ViewBuilder+    func body(content: Content) -> some View {+        if reduceTransparency {+            content+        } else {+            content.glassEffect(.regular.interactive())+        }+    }+}++extension View {+    /// Reduce-Transparency-aware variant of `.background(material)` (default `Rectangle()`).+    func adaptiveMaterialBackground(_ material: Material = .regularMaterial) -> some View {+        modifier(AdaptiveMaterialBackground(material: material, shape: Rectangle()))+    }++    /// Reduce-Transparency-aware variant of `.background(material, in: shape)`.+    func adaptiveMaterialBackground<S: Shape>(_ material: Material = .regularMaterial, in shape: S) -> some View {+        modifier(AdaptiveMaterialBackground(material: material, shape: shape))+    }++    /// Reduce-Transparency-aware variant of `.glassEffect(.regular.interactive())`.+    /// Returns the view unchanged when Reduce Transparency is on.+    func adaptiveGlassEffect() -> some View {+        modifier(AdaptiveGlassEffect())+    }+}

diff --git a/prism/prismApp.swift b/prism/prismApp.swiftindex b432123..7cabee3 100644--- a/prism/prismApp.swift+++ b/prism/prismApp.swift@@ -210,6 +210,7 @@ struct PrismApp: App {                 ImageDetailWindow(data: data)                     .environment(settings)                     .environment(\.imageServices, imageServices)+                    .applyTheme(settings: settings, systemObserver: systemColorSchemeObserver)             }         }         .windowResizability(.contentMinSize)

diff --git a/prism/Views/MermaidPreviewCard.swift b/prism/Views/MermaidPreviewCard.swiftindex fdb47d8..8ad003c 100644--- a/prism/Views/MermaidPreviewCard.swift+++ b/prism/Views/MermaidPreviewCard.swift@@ -177,7 +177,7 @@ struct MermaidPreviewCard: View {                     .font(.caption)             }             .buttonStyle(.bordered)-            .glassEffect(.regular.interactive())+            .adaptiveGlassEffect()             .accessibilityHint(LocalizedStringKey("Opens the rendered diagram"))              Button {@@ -187,7 +187,7 @@ struct MermaidPreviewCard: View {                     .font(.caption)             }             .buttonStyle(.bordered)-            .glassEffect(.regular.interactive())+            .adaptiveGlassEffect()             .accessibilityHint(LocalizedStringKey("Copies the diagram source code to clipboard"))         }         .padding(8)

diff --git a/prism/Views/ImageBlockView.swift b/prism/Views/ImageBlockView.swiftindex 4337f69..79325c6 100644--- a/prism/Views/ImageBlockView.swift+++ b/prism/Views/ImageBlockView.swift@@ -230,7 +230,7 @@ struct ImageBlockView: View {                     .font(.caption)             }             .buttonStyle(.bordered)-            .glassEffect(.regular.interactive())+            .adaptiveGlassEffect()              Button {                 dismissOverlay()@@ -240,7 +240,7 @@ struct ImageBlockView: View {                     .font(.caption)             }             .buttonStyle(.bordered)-            .glassEffect(.regular.interactive())+            .adaptiveGlassEffect()         }         .padding(8)     }

diff --git a/prism/Views/MetadataView.swift b/prism/Views/MetadataView.swiftindex 59f7287..9a1f684 100644--- a/prism/Views/MetadataView.swift+++ b/prism/Views/MetadataView.swift@@ -47,7 +47,7 @@ struct MetadataView: View {             }         }         .padding()-        .background(.regularMaterial, in: RoundedRectangle(cornerRadius: 12))+        .adaptiveMaterialBackground(in: RoundedRectangle(cornerRadius: 12))         .accessibilityElement(children: .contain)     } 

diff --git a/prism/Views/Search/InlineSearchBar.swift b/prism/Views/Search/InlineSearchBar.swiftindex ba315e3..de5396e 100644--- a/prism/Views/Search/InlineSearchBar.swift+++ b/prism/Views/Search/InlineSearchBar.swift@@ -57,7 +57,7 @@ struct InlineSearchBar: View {         }         .padding(.horizontal, 16)         .padding(.vertical, 10)-        .background(.regularMaterial)+        .adaptiveMaterialBackground()         .onAppear {             isSearchFieldFocused = true         }

diff --git a/prism/Views/ToastNotification.swift b/prism/Views/ToastNotification.swiftindex dbc54e8..45774e1 100644--- a/prism/Views/ToastNotification.swift+++ b/prism/Views/ToastNotification.swift@@ -33,7 +33,7 @@ struct ToastNotification: View {                 .font(.subheadline)                 .padding(.horizontal, 16)                 .padding(.vertical, 10)-                .background(.regularMaterial, in: Capsule())+                .adaptiveMaterialBackground(in: Capsule())                 .accessibilityLabel(message)                 .accessibilityAddTraits(.isStaticText)                 .transition(

diff --git a/prism/Views/ReloadBanner.swift b/prism/Views/ReloadBanner.swiftindex ef95b2e..2495327 100644--- a/prism/Views/ReloadBanner.swift+++ b/prism/Views/ReloadBanner.swift@@ -50,7 +50,7 @@ struct ReloadBanner: View {         }         .padding(.horizontal)         .padding(.vertical, 10)-        .background(.regularMaterial)+        .adaptiveMaterialBackground()         .clipShape(RoundedRectangle(cornerRadius: 12))         .shadow(radius: 2)         .padding()

diff --git a/prism/Views/FootnotePopoverView.swift b/prism/Views/FootnotePopoverView.swiftindex fe2a25c..31237ac 100644--- a/prism/Views/FootnotePopoverView.swift+++ b/prism/Views/FootnotePopoverView.swift@@ -58,7 +58,7 @@ struct FootnotePopoverView: View {         #if os(macOS)         .frame(idealWidth: 400, maxWidth: 500)         .frame(maxHeight: 400)-        .background(.regularMaterial)+        .adaptiveMaterialBackground()         #else         .presentationDetents([.medium])         .presentationDragIndicator(.visible)

diff --git a/prism/Views/NotePopover.swift b/prism/Views/NotePopover.swiftindex 27313c5..866ce41 100644--- a/prism/Views/NotePopover.swift+++ b/prism/Views/NotePopover.swift@@ -82,7 +82,7 @@ struct NotePopover: View {         .frame(minWidth: 450, idealWidth: 500, maxWidth: 900)         .frame(maxHeight: 600)         .fixedSize(horizontal: false, vertical: true)-        .background(.regularMaterial)+        .adaptiveMaterialBackground()         #endif     } }

diff --git a/prism/Views/ImageDetailWindow.swift b/prism/Views/ImageDetailWindow.swiftindex 18dfd09..2458c0e 100644--- a/prism/Views/ImageDetailWindow.swift+++ b/prism/Views/ImageDetailWindow.swift@@ -231,7 +231,7 @@ struct ImageDetailWindow: View {                     .font(.caption)                     .padding(.horizontal, 8)                     .padding(.vertical, 4)-                    .background(.regularMaterial)+                    .adaptiveMaterialBackground()                     .clipShape(Capsule())                     .accessibilityLabel(LocalizedStringKey("Zoom level \(Int(scale * 100)) percent"))             }

diff --git a/prism/Views/AccessibleTableView.swift b/prism/Views/AccessibleTableView.swiftindex c4af351..99b24d9 100644--- a/prism/Views/AccessibleTableView.swift+++ b/prism/Views/AccessibleTableView.swift@@ -256,7 +256,7 @@ struct AccessibleTableView: View {                 .font(.caption)         }         .buttonStyle(.bordered)-        .glassEffect(.regular.interactive())+        .adaptiveGlassEffect()         .padding(8)         .accessibilityLabel(displayMode.toggleAccessibilityLabel)         .contextMenu {

diff --git a/prismTests/AdaptiveMaterialTests.swift b/prismTests/AdaptiveMaterialTests.swiftnew file mode 100644index 0000000..59eea05--- /dev/null+++ b/prismTests/AdaptiveMaterialTests.swift@@ -0,0 +1,41 @@+//+//  AdaptiveMaterialTests.swift+//  prismTests+//+//  Verifies the invariant that every concrete `ThemeColors.surface1` is fully+//  opaque. The Reduce Transparency fallback (`AdaptiveMaterialBackground`) paints+//  `themeColors.surface1` in place of `Material`, so a future translucent-ification+//  of `surface1` would silently defeat accessibility audit finding H4 (T-1044).+//++import Testing+import SwiftUI+@testable import prism++@Suite("AdaptiveMaterial Tests")+struct AdaptiveMaterialTests {+    @Test("PrismLightColors.surface1 is fully opaque")+    func prismLightSurface1Opaque() {+        #expect(ContrastChecker.alphaComponent(PrismLightColors().surface1) == 1)+    }++    @Test("PrismDarkColors.surface1 is fully opaque")+    func prismDarkSurface1Opaque() {+        #expect(ContrastChecker.alphaComponent(PrismDarkColors().surface1) == 1)+    }++    @Test("ClassicLightColors.surface1 is fully opaque")+    func classicLightSurface1Opaque() {+        #expect(ContrastChecker.alphaComponent(ClassicLightColors().surface1) == 1)+    }++    @Test("ClassicDarkColors.surface1 is fully opaque")+    func classicDarkSurface1Opaque() {+        #expect(ContrastChecker.alphaComponent(ClassicDarkColors().surface1) == 1)+    }++    @Test("RefractionColors.surface1 is fully opaque")+    func refractionSurface1Opaque() {+        #expect(ContrastChecker.alphaComponent(RefractionColors().surface1) == 1)+    }+}

diff --git a/prismTests/WCAGContrastTests.swift b/prismTests/WCAGContrastTests.swiftindex b68d7fb..3b68321 100644--- a/prismTests/WCAGContrastTests.swift+++ b/prismTests/WCAGContrastTests.swift@@ -50,14 +50,41 @@ struct ContrastChecker {      /// Extracts RGB components from a Color     private static func rgbComponents(_ color: Color) -> (r: Double, g: Double, b: Double) {+        let rgba = rgbaComponents(color)+        return (rgba.red, rgba.green, rgba.blue)+    }++    /// Extracts the alpha component from a Color (1.0 for opaque colors).+    static func alphaComponent(_ color: Color) -> Double {+        rgbaComponents(color).alpha+    }++    /// Cross-platform sRGB resolution. The macOS branch returns all-zeroes if+    /// the colour cannot be projected into sRGB so callers see "fully unset"+    /// rather than a partially-valid colour.+    private struct RGBAComponents {+        let red: Double+        let green: Double+        let blue: Double+        let alpha: Double+    }++    private static func rgbaComponents(_ color: Color) -> RGBAComponents {         #if canImport(UIKit)         let uiColor = UIColor(color)-        var r: CGFloat = 0, g: CGFloat = 0, b: CGFloat = 0-        uiColor.getRed(&r, green: &g, blue: &b, alpha: nil)-        return (Double(r), Double(g), Double(b))+        var red: CGFloat = 0, green: CGFloat = 0, blue: CGFloat = 0, alpha: CGFloat = 0+        uiColor.getRed(&red, green: &green, blue: &blue, alpha: &alpha)+        return RGBAComponents(red: Double(red), green: Double(green), blue: Double(blue), alpha: Double(alpha))         #elseif canImport(AppKit)-        let nsColor = NSColor(color).usingColorSpace(.sRGB) ?? NSColor.black-        return (nsColor.redComponent, nsColor.greenComponent, nsColor.blueComponent)+        guard let nsColor = NSColor(color).usingColorSpace(.sRGB) else {+            return RGBAComponents(red: 0, green: 0, blue: 0, alpha: 0)+        }+        return RGBAComponents(+            red: Double(nsColor.redComponent),+            green: Double(nsColor.greenComponent),+            blue: Double(nsColor.blueComponent),+            alpha: Double(nsColor.alphaComponent)+        )         #endif     } }

diff --git a/CHANGELOG.md b/CHANGELOG.mdindex d0bd3d8..8b9cdac 100644--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -17,6 +17,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 - `footnote-badge-a11y` smolspec (T-1036) for VoiceOver discoverability and operability of inline footnote badges, covering paragraph-level accessibility-label rebuild and per-paragraph accessibility actions in `HighlightedInlineText`. Decision log captures the pivot away from a Textual fork change to a single-file view-layer approach. Five linearly-dependent tasks live under `specs/footnote-badge-a11y/`. - **Debug-only:** Settings → About now shows a "Build" row beneath "Version" with the short git commit hash the build was produced from, suffixed `-dirty` when the working tree had uncommitted changes (and `unknown` when built outside a git checkout). A new `Tools/stamp-commit-hash.sh` build phase writes `GitCommit` into the bundled `Info.plist` using `PlistBuddy`; the script bails early when `CONFIGURATION` isn't `Debug`, so Release/TestFlight/App Store builds never carry the key. The Settings UI and `Bundle.appCommitHash` accessor are wrapped in `#if DEBUG` as a second line of defence. The phase is marked always-out-of-date so the Debug value refreshes on every build. - Footnote badges are now discoverable and operable for VoiceOver (T-1036). New `FootnoteAccessibility` helper (`prism/Services/FootnoteAccessibility.swift`) extracts unique footnote references in first-occurrence order and rebuilds a paragraph-level accessibility label that substitutes each resolvable `[^id]` with the localised inline phrase "footnote N". `HighlightedInlineText` applies a private `FootnoteAccessibilityModifier` that overrides the paragraph's accessibility label and exposes one "Show footnote N" action per unique reference via `.accessibilityActions { … }`. Each action opens the existing `prism://footnote/{id}` URL through `@Environment(\.openURL)`, reusing the tap-routing flow already wired in `DocumentReaderView`. The modifier is a no-op when no resolvable references are present, so paragraphs without footnotes keep their auto-derived narration. New localised keys `a11y.footnote.inline %lld` and `a11y.footnote.action %lld` added to `prism/Localizable.xcstrings`. Helpers covered by new unit tests in `prismTests/FootnoteAccessibilityTests.swift`.+- Translucent overlay surfaces now honour the system Reduce Transparency accessibility setting on both iOS and macOS (T-1044, audit finding H4). New `prism/Theme/AdaptiveMaterial.swift` introduces two `ViewModifier` types — `AdaptiveMaterialBackground<S: Shape>` and `AdaptiveGlassEffect` — that read `@Environment(\.accessibilityReduceTransparency)` and swap `.background(.regularMaterial, in:)` for an opaque `themeColors.surface1` fill, and drop `.glassEffect(.regular.interactive())` to a no-op (the underlying `.buttonStyle(.bordered)` renders its own opaque background) when the setting is on. Applied at 12 sites: metadata header, inline search bar, toast notifications, reload banner, macOS footnote popover, note popover, macOS image-detail zoom badge, accessible-table mode-toggle button, and the four mermaid/image overlay buttons in `MermaidPreviewCard` and `ImageBlockView`. The `image-detail` `WindowGroup` in `prism/prismApp.swift` also gains `.applyTheme(...)` so it correctly resolves `themeColors` (and now honours the user's selected theme — a latent-bug fix). New `prismTests/AdaptiveMaterialTests.swift` locks in the invariant that `surface1` is fully opaque (alpha == 1) for every concrete theme (`PrismLight`, `PrismDark`, `ClassicLight`, `ClassicDark`, `Refraction`) so future translucent-ification of `surface1` cannot silently defeat the fallback. Reuses the cross-platform colour-component bridge already in `ContrastChecker` via a new `alphaComponent(_:)` sibling.  ### Fixed 

diff --git a/specs/reduce-transparency-a11y/smolspec.md b/specs/reduce-transparency-a11y/smolspec.mdnew file mode 100644index 0000000..1fdfdbf--- /dev/null+++ b/specs/reduce-transparency-a11y/smolspec.md@@ -0,0 +1,92 @@+# Reduce Transparency (a11y H4)++Tracks Transit ticket **T-1044** (chore, milestone 1.0.0). Source: accessibility audit finding H4 in `docs/accessibility-review.md`.++## Overview++Prism never reads `Environment(\.accessibilityReduceTransparency)`, so users who enable Reduce Transparency in their OS still see translucent `regularMaterial` and Liquid Glass surfaces (popovers, banners, capsules, overlay buttons). Add a reusable view modifier that swaps those surfaces for an opaque theme color when the user has Reduce Transparency turned on, then apply it at every site that today uses `.background(.regularMaterial, …)` or `.glassEffect(.regular.interactive())`.++## Requirements++- The system MUST read `@Environment(\.accessibilityReduceTransparency)` and replace `regularMaterial` surfaces with an opaque `themeColors.surface1` fill when the value is `true`.+- The system MUST drop `.glassEffect(.regular.interactive())` to a no-op pass-through when `accessibilityReduceTransparency` is `true`, relying on the underlying `.buttonStyle(.bordered)` to render its own opaque background (this avoids guessing the implicit shape `glassEffect` uses on a bordered button).+- The system MUST render the original `Material` / `glassEffect` treatment unchanged when `accessibilityReduceTransparency` is `false` (no visual regression for users who have the setting off).+- The system MUST expose the swap as reusable `View` modifiers so call sites change by a single line each.+- The system MUST apply the new modifier at every site listed in the *In Scope* call-site table.+- The system MUST ensure `themeColors` is available at every call site — including the `image-detail` `WindowGroup` in `prism/prismApp.swift:208`, which today is the only `WindowGroup` in the app that does NOT call `.applyTheme(...)`.+- The system MUST keep working on both iOS 26 (iPhone / iPad) and macOS 26, including macOS-only call sites.+- The system SHOULD preserve every existing shape argument (`Capsule()`, `RoundedRectangle(cornerRadius: 12)`, default) at each call site — the modifier MUST accept an optional shape and fall through to the same default `.background(_, in:)` SwiftUI uses today.+- The system SHOULD assert in tests that `surface1` is fully opaque (alpha == 1) for every concrete theme implementation, so a future translucent-ification of `surface1` is caught by `make test-quick`.++## Implementation Approach++### New file — `prism/Theme/AdaptiveMaterial.swift`++- Define two `ViewModifier` types — `AdaptiveMaterialBackground<S: Shape>` and `AdaptiveGlassEffect` — each reading `@Environment(\.accessibilityReduceTransparency)` and `@Environment(\.themeColors)`.+- Use a `@ViewBuilder` body inside each modifier so the two branches can return different opaque `View` types. SwiftUI's `.background(_:in:)` is generic on `ShapeStyle`; the two branches need different concrete `ShapeStyle` types (`Material` vs `Color`), and `@ViewBuilder` is the SwiftUI-idiomatic way to handle that without `AnyShapeStyle` or `AnyView`.+- Modifier bodies:+  - `AdaptiveMaterialBackground<S: Shape>`:+    - `if reduceTransparency { content.background(colors.surface1, in: shape) } else { content.background(material, in: shape) }`+    - For the shape-less overload, pass `Rectangle()` (the implicit default that `.background(material)` uses).+  - `AdaptiveGlassEffect`:+    - `if reduceTransparency { content } else { content.glassEffect(.regular.interactive()) }`+    - No fallback shape, no `surface1` fill — the call sites all sit on `.buttonStyle(.bordered)`, which already renders an opaque background. Letting the bordered button render itself is simpler than guessing the system's private capsule shape and risking platform-divergent rendering.+- Expose three `View` extension entry points:+  - `adaptiveMaterialBackground(_ material: Material = .regularMaterial) -> some View`+  - `adaptiveMaterialBackground<S: Shape>(_ material: Material = .regularMaterial, in shape: S) -> some View`+  - `adaptiveGlassEffect() -> some View`++**Pattern reference**: follow `prism/Theme/ThemedBackground.swift` (the in-repo template for "ViewModifier + extension View" style modifiers; the new file lives in the same directory).++### Required env-propagation fix++`prism/prismApp.swift:208` declares `WindowGroup("Image", id: "image-detail", …)` but is the only `WindowGroup` in the app that does NOT call `.applyTheme(settings:systemObserver:)` (compare lines 183, 302, 345, 358). Today this is latent — `ImageDetailWindow` paints `.regularMaterial` which is system-adaptive — but the new modifier reads `themeColors`, so without `.applyTheme(...)` the window would fall back to `PrismLightColors()` and break the dark theme. Add `.applyTheme(settings: settings, systemObserver: systemColorSchemeObserver)` to the `image-detail` `WindowGroup` after the existing `.environment(...)` chain.++### Call-site changes (one-line swaps)++| File | Line | Platform | Replacement |+|---|---|---|---|+| `prism/Views/MetadataView.swift` | 50 | iOS+macOS | `.adaptiveMaterialBackground(in: RoundedRectangle(cornerRadius: 12))` |+| `prism/Views/MermaidPreviewCard.swift` | 178 | iOS+macOS | `.adaptiveGlassEffect()` |+| `prism/Views/MermaidPreviewCard.swift` | 187 | iOS+macOS | `.adaptiveGlassEffect()` |+| `prism/Views/Search/InlineSearchBar.swift` | 60 | iOS+macOS | `.adaptiveMaterialBackground()` |+| `prism/Views/ToastNotification.swift` | 36 | iOS+macOS | `.adaptiveMaterialBackground(in: Capsule())` |+| `prism/Views/ReloadBanner.swift` | 53 | iOS+macOS | `.adaptiveMaterialBackground()` |+| `prism/Views/FootnotePopoverView.swift` | 61 | macOS only (already inside `#if os(macOS)`) | `.adaptiveMaterialBackground()` |+| `prism/Views/NotePopover.swift` | 85 | iOS+macOS | `.adaptiveMaterialBackground()` |+| `prism/Views/ImageDetailWindow.swift` | 234 | macOS only (the whole file is macOS) | `.adaptiveMaterialBackground()` |+| `prism/Views/AccessibleTableView.swift` | 258 | iOS+macOS | `.adaptiveGlassEffect()` |+| `prism/Views/ImageBlockView.swift` | 233 | iOS+macOS | `.adaptiveGlassEffect()` |+| `prism/Views/ImageBlockView.swift` | 243 | iOS+macOS | `.adaptiveGlassEffect()` |++`ImageBlockView` rows are included even though the audit didn't list them: the file's own comments (`ImageBlockView.swift:186, 221`) say its overlay buttons are kept in sync with `MermaidPreviewCard`. Fixing one without the other would create a visible inconsistency in the linked-image overlay under Reduce Transparency.++### Tests — `prismTests/AdaptiveMaterialTests.swift` (Swift Testing)++Two assertion groups:++1. **`surface1` opacity invariant.** For each concrete theme (`PrismLightColors`, `PrismDarkColors`, `ClassicLightColors`, `ClassicDarkColors`, `RefractionColors`), assert `surface1.cgColor?.alpha == 1`. This is the regression class that matters: if someone accidentally introduces translucency in `surface1`, the Reduce Transparency fallback silently becomes translucent and the whole fix is defeated.+2. **Pure colour-resolution helper.** If the modifier extracts a static helper like `resolvedFallback(reduceTransparency:colors:) -> Color?`, assert `nil` when `reduceTransparency == false`, and `colors.surface1` when `true`, for both light and dark themes. If the modifier inlines the decision and no helper exists, drop this group — don't fabricate one just to test it.++### Out of Scope++- **Other translucent surfaces the audit missed** — `prism/Views/CompactBottomToolbar.swift:75`, `prism/Views/MermaidDiagramWindow.swift:226`, and `prism/prismApp.swift:374` (download-progress overlay). These use `.regularMaterial` and would benefit from the same modifier, but the H4 audit didn't list them. Track in a follow-up Transit ticket so this chore stays scoped to the audit's published surface list.+- **`.fill(.ultraThinMaterial)` callers** — `prism/Views/NoteRow.swift:126`, `prism/Views/InlineNoteView.swift:82`, `prism/Views/BubbleNoteView.swift:26`, `prism/Views/ThreadGroupView.swift:90`. These are note-content surfaces (fills *inside* a note bubble), not overlay popovers / banners — different visual role in the hierarchy. The H4 audit explicitly framed itself around popover / overlay surfaces; note-content fills are a separate visual question (does an opaque note bubble still read as a note?) that deserves its own ticket.+- **Other accessibility audit findings** — H1, H2, H3, H5, M1–M5, L1+. Each is a separate Transit ticket.+- **High-contrast theme variant / `accessibilityContrast` reads** — that is finding H5 / T-1045.+- **Snapshot or XCUITest harness for visual a11y regressions.** Prism has no snapshot-test infrastructure today; adding one is a separate multi-day project. Visual confirmation in this chore is the manual sweep in task 4.+- **Animated transition when the user toggles Reduce Transparency at runtime.** SwiftUI re-publishes the environment naturally and the surface swap will be instant. A cross-fade would be a UX decision separate from H4.++### Dependencies++- Reads `themeColors` from `@Environment(\.themeColors)` (populated by `ThemeModifier` in `prism/Theme/ThemeEnvironment.swift:42`). All current call sites sit inside a `WindowGroup` that applies `ThemeModifier` — except `ImageDetailWindow`, which is fixed in this spec.+- No new third-party packages. `accessibilityReduceTransparency` is built into SwiftUI on both iOS and macOS.++## Risks and Assumptions++- **Risk: `surface1` looks wrong against the active theme's `background`.** Mitigation: every concrete theme defines `surface1` as the "elevated surface" colour designed to sit above `background` (`PrismLightColors.swift:11` → `#FCFCFE` on `#EEF0FA`; `PrismDarkColors.swift:13` → `#101A33` on darker; `ClassicColors.swift:8/84` → `.secondarySystemBackground` on `.systemBackground`; `RefractionColors.swift:20` → `#FFFFFF` on the gradient field with an explicit `"pure white reading card"` annotation). The manual sweep in task 4 covers all four themes × light/dark × Reduce Transparency on/off, so a contrast failure surfaces before merge.+- **Risk: Adding `.applyTheme(...)` to the `image-detail` `WindowGroup` changes the appearance of that window for users on a non-default theme.** This is technically a behaviour change beyond the audit's literal scope, but the change is to *correctly* apply the user's selected theme to a window that today silently uses the light-theme default — i.e. it fixes an existing latent bug. Acceptable.+- **Risk: `.buttonStyle(.bordered)` alone is not opaque enough to read clearly under Reduce Transparency.** Mitigation: bordered button style fills with a system-adaptive material that is already much more opaque than `.glassEffect`. If the manual sweep in task 4 finds a specific button reading poorly, the fix is a `.background(colors.surface1)` *behind* the bordered button at that one call site — not a redesign of the modifier.+- **Risk: A hidden translucent surface outside the listed 12 sites stays unfixed.** Mitigation: the Out of Scope section enumerates the discovered-but-deferred sites by file and line so they can't be silently forgotten; a follow-up Transit ticket should track them.+- **Assumption:** Every listed call site is inside the `themeColors` environment. Confirmed for the 12 sites: 11 are inside the primary document `WindowGroup` (line 183) which applies `ThemeModifier`; `ImageDetailWindow` is the exception and is fixed by this spec.+- **Prerequisite:** None — the change is additive and behind an environment read that defaults to `false` on devices that have the setting off.

diff --git a/specs/reduce-transparency-a11y/decision_log.md b/specs/reduce-transparency-a11y/decision_log.mdnew file mode 100644index 0000000..c18c624--- /dev/null+++ b/specs/reduce-transparency-a11y/decision_log.md@@ -0,0 +1,170 @@+# Decision Log: Reduce Transparency a11y++## Decision 1: Use `@ViewBuilder` branching, not `AnyShapeStyle` / `AnyView`++**Date**: 2026-05-20+**Status**: accepted++### Context++`AdaptiveMaterialBackground` must paint either `Material` (translucent+default) or `Color` (opaque fallback) into the same `.background(_:in:)`+call. `.background(_:in:)` is generic on `ShapeStyle`, and the two+branches resolve to different concrete `ShapeStyle` types.++### Decision++Use a `@ViewBuilder` body inside the `ViewModifier` and return the two+branches as distinct `some View` types. `_ConditionalContent` glues+them together. No `AnyShapeStyle`, no `AnyView`.++### Rationale++- `@ViewBuilder` is the SwiftUI-idiomatic mechanism for type-divergent+  branches inside a view body.+- `AnyView` erases view identity and forces SwiftUI to recompute diffs+  from scratch on each render, which would matter at the+  `MermaidPreviewCard` / `ImageBlockView` overlay sites that render on+  every visible row of a long document.+- `AnyShapeStyle` would solve the type mismatch but propagates the+  erasure through every consumer of the modifier.+- The branching variable (`accessibilityReduceTransparency`) is an+  OS-level a11y flag, not per-frame state, so `_ConditionalContent`+  identity is stable across renders.++### Alternatives Considered++- **`AnyShapeStyle` wrapping both branches**: Rejected — pushes type+  erasure into the modifier signature and gives nothing back over the+  `@ViewBuilder` approach.+- **`AnyView` wrapping the whole body**: Rejected — loses view identity+  and hits the hot render path on long documents with mermaid/image+  overlays.++### Consequences++**Positive:**+- Identity-preserving for both branches.+- No type erasure leaks into call sites.++**Negative:**+- The `AdaptiveMaterialBackground` struct has two generic parameters+  (`S: Shape`) instead of one erased one. Acceptable — the call sites+  already pin a concrete shape.++---++## Decision 2: `AdaptiveGlassEffect` is a pass-through under Reduce Transparency, not a `Capsule` fill++**Date**: 2026-05-20+**Status**: accepted++### Context++`.glassEffect(.regular.interactive())` is applied to overlay buttons+that already sit on `.buttonStyle(.bordered)`. When Reduce Transparency+is on, we need an opaque fallback that doesn't visually break the+button.++Initial idea: paint `themeColors.surface1` in a `Capsule()` underneath+the button so the glass swap leaves a visible opaque button shape. The+problem is that the shape `.glassEffect` chooses for a bordered button+is system-defined and undocumented — guessing `Capsule()` could produce+visible misalignment on either iOS or macOS.++### Decision++When Reduce Transparency is on, `AdaptiveGlassEffect` returns the+`content` unchanged. The underlying `.buttonStyle(.bordered)` provides+its own opaque background, which the system already adapts for Reduce+Transparency.++### Rationale++- Bordered button style already renders a system-adaptive opaque fill+  that meets the accessibility intent.+- Painting a guessed shape underneath risks platform-divergent+  rendering between iOS and macOS, where the bordered button's actual+  shape may differ from our guess.+- Letting the system render the button keeps the visual treatment+  consistent with every other bordered button in the app.++### Alternatives Considered++- **Paint `Capsule()` with `surface1`**: Rejected — guesses the+  bordered button's internal shape and would mis-render if the system+  uses a different shape.+- **Paint a `RoundedRectangle` with a tuned corner radius**: Same+  rejection reason — still a guess.++### Consequences++**Positive:**+- Zero risk of platform-divergent shape rendering.+- One less modifier on the view body in the fallback branch.++**Negative:**+- The fallback relies on `.buttonStyle(.bordered)` being preserved at+  every call site. If a future change drops `.bordered` from one of+  the call sites, the Reduce Transparency fallback at that site+  silently becomes "no background at all". The smolspec call-site+  table flags this dependency, and the task description for step 3+  explicitly says to preserve the bordered button at each site.++---++## Decision 3: Add `.applyTheme(...)` to the `image-detail` `WindowGroup`++**Date**: 2026-05-20+**Status**: accepted++### Context++`AdaptiveMaterialBackground` reads `@Environment(\.themeColors)`. Every+`WindowGroup` in `prismApp.swift` calls `.applyTheme(...)` except the+`image-detail` group at `prism/prismApp.swift:208`. Without the+modifier, `themeColors` falls back to the `PrismLightColors()` default+defined on the environment key, so the new fallback would always paint+the light-theme `surface1` colour in that window — broken under any+dark theme.++### Decision++Add `.applyTheme(settings: settings, systemObserver: systemColorSchemeObserver)`+to the `image-detail` `WindowGroup` after the existing `.environment(...)`+chain.++### Rationale++- Required for the new modifier to render correctly when the user is on+  any non-default theme.+- Fixes an existing latent bug: today `ImageDetailWindow` silently+  ignores the user's selected theme because `themeColors` falls through+  to the environment default. The window paints `.regularMaterial`,+  which is system-adaptive and masks the bug visually, but the theme+  isn't actually applied.++### Alternatives Considered++- **Special-case `ImageDetailWindow` to read theme settings directly**:+  Rejected — duplicates `ThemeModifier` logic and breaks the+  consistency that every other window applies the same theme stack.+- **Hard-code the fallback colour to a system colour like+  `.secondarySystemBackground`**: Rejected — defeats the purpose of+  the theme system. Users on `RefractionColors` or `PrismDarkColors`+  would see the wrong fallback.++### Consequences++**Positive:**+- The image-detail window now correctly applies the user's selected+  theme (a latent-bug fix).+- The new Reduce Transparency fallback renders consistently in every+  window.++**Negative:**+- Technically a behaviour change beyond the audit's literal scope. The+  visible difference for any user is "image-detail window now matches+  the theme I picked" — acceptable.++---

diff --git a/specs/reduce-transparency-a11y/implementation.md b/specs/reduce-transparency-a11y/implementation.mdnew file mode 100644index 0000000..b6c331c--- /dev/null+++ b/specs/reduce-transparency-a11y/implementation.md@@ -0,0 +1,123 @@+# Implementation: Reduce Transparency a11y (T-1044)++Source spec: [smolspec.md](smolspec.md) · [decision_log.md](decision_log.md) · [tasks.md](tasks.md)++## Beginner Level++### What Changed+macOS and iOS have an accessibility setting called **Reduce Transparency**. When users turn it on, they're saying "blurry/frosted-glass surfaces are hard for me to read — make them solid colours." Prism wasn't listening to that setting. Popovers, banners, toast messages, and the little overlay buttons on diagrams and images were always rendered as translucent "frosted glass" surfaces, even for users who had asked the OS to stop doing that.++This change adds a small helper that watches for the Reduce Transparency setting and, when it's on, paints those surfaces with a solid theme colour instead. We swap 12 specific spots in the app over to use the helper.++### Why It Matters+- People with low vision, certain cognitive disabilities, or motion sensitivity rely on Reduce Transparency to make UI text readable.+- This is one of several fixes from an accessibility audit (finding H4 in `docs/accessibility-review.md`).+- It's a small, contained change with no risk to users who don't have the setting on — they see the exact same translucent surfaces as before.++### Key Concepts+- **ViewModifier**: A SwiftUI helper that wraps a view and changes how it renders. Think of it like a sticker you apply to a button to change its appearance.+- **Environment**: SwiftUI's way of passing values (like "is the user in dark mode?" or "is Reduce Transparency on?") down to every view in the app without manually wiring them.+- **`Material`** vs **`Color`**: `Material` is the "frosted glass" effect; `Color` is a flat opaque fill. The fix is "use `Color` instead of `Material` when the setting is on."++---++## Intermediate Level++### Changes Overview+- **New file**: `prism/Theme/AdaptiveMaterial.swift` (58 lines) — two `ViewModifier` types and three `View` extensions.+- **12 call-site swaps** in `prism/Views/*` — every `.background(.regularMaterial, ...)` and `.glassEffect(.regular.interactive())` listed in the audit becomes `.adaptiveMaterialBackground(...)` or `.adaptiveGlassEffect()`.+- **`prismApp.swift:213`** — the `image-detail` `WindowGroup` now calls `.applyTheme(...)` like every other `WindowGroup` does. This was a latent bug: `ImageDetailWindow` previously fell back to the light-theme default for `themeColors` because nothing populated the environment.+- **New test file**: `prismTests/AdaptiveMaterialTests.swift` asserts `surface1.alpha == 1` for all 5 concrete `ThemeColors` implementations.+- **Test helper consolidation**: extended `ContrastChecker` (in `prismTests/WCAGContrastTests.swift`) with an `alphaComponent(_:)` static method and refactored its internal cross-platform RGB(A) bridge into a single shared private helper. `AdaptiveMaterialTests` calls the shared helper instead of duplicating the platform-specific `UIColor`/`NSColor` extraction.++### Implementation Approach+The two modifiers each read the relevant environment values and use `@ViewBuilder` to return a different `some View` per branch:++```swift+struct AdaptiveMaterialBackground<S: Shape>: ViewModifier {+    @Environment(\.accessibilityReduceTransparency) private var reduceTransparency+    @Environment(\.themeColors) private var colors+    let material: Material+    let shape: S++    @ViewBuilder func body(content: Content) -> some View {+        if reduceTransparency {+            content.background(colors.surface1, in: shape)+        } else {+            content.background(material, in: shape)+        }+    }+}+```++`AdaptiveGlassEffect` is even simpler: when Reduce Transparency is on it returns `content` unchanged and relies on the underlying `.buttonStyle(.bordered)` (always present at every call site) to render an opaque fill. No fallback `Capsule()` is painted — that would require guessing the bordered button's internal shape, which is undocumented and platform-specific.++Three `View` extensions wrap the modifiers:+- `adaptiveMaterialBackground(_ material:)` — shape-less, equivalent to `.background(material)`+- `adaptiveMaterialBackground(_ material:in:)` — shaped, equivalent to `.background(material, in: shape)`+- `adaptiveGlassEffect()` — equivalent to `.glassEffect(.regular.interactive())`++### Trade-offs+- **`@ViewBuilder` over `AnyView` / `AnyShapeStyle`**: keeps view identity stable and avoids erasure costs at hot render sites (mermaid/image overlay buttons render on every visible row of a long document). See decision log #1.+- **`AdaptiveGlassEffect` as pass-through, not shaped fill**: avoids guessing the system's private shape for `.buttonStyle(.bordered) + .glassEffect`. The trade-off is a hard dependency on `.bordered` staying at every call site — flagged in the smolspec and in tasks.md step 3. See decision log #2.+- **`image-detail` `WindowGroup` gets `.applyTheme(...)`**: technically a behaviour change beyond audit scope, but the change is to *correctly* apply the user's theme to a window that today silently used the light-theme default. Acceptable latent-bug fix. See decision log #3.+- **Test for opacity invariant, not behaviour**: the spec explicitly accepts that `AdaptiveMaterialBackground`'s branch selection is trivial enough not to need a behaviour test; the real regression class is "someone makes `surface1` translucent and breaks the fallback silently." That's what `AdaptiveMaterialTests` catches.++---++## Expert Level++### Technical Deep Dive+- **Environment dependency footprint**: `AdaptiveMaterialBackground` reads two environment values (`accessibilityReduceTransparency`, `themeColors`); `AdaptiveGlassEffect` reads one. Both are OS-level / app-level values that change rarely, so SwiftUI's diffing only invalidates the modifier when those specific values flip — not on every render.+- **Identity stability**: `@ViewBuilder` returns `_ConditionalContent<TrueBranch, FalseBranch>`, which preserves view identity *within* each branch. Switching branches (e.g. user toggling Reduce Transparency at runtime) does change identity once, but no animation is wired in — SwiftUI's environment re-publish handles the swap as an instant content replacement, which is the expected UX.+- **Generic instantiation cost**: `AdaptiveMaterialBackground<S: Shape>` produces one specialised type per shape used at call sites: `Rectangle`, `RoundedRectangle`, `Capsule`. Three specialisations total. Negligible.+- **`themeColors` fallback hazard**: every `WindowGroup` that uses the new modifier must apply `ThemeModifier` (via `.applyTheme(...)`), otherwise `@Environment(\.themeColors)` falls through to the `PrismLightColors()` default and the Reduce Transparency fallback always paints the light-theme `surface1` regardless of the active theme. Confirmed for all 12 call sites: 11 are inside the primary document `WindowGroup` (which applies `ThemeModifier`); the `image-detail` `WindowGroup` is the one exception and is fixed in this change.+- **`AdaptiveGlassEffect` correctness**: the pass-through only works because every call site sits on `.buttonStyle(.bordered)`. The bordered button style fills with a system-adaptive material that is significantly more opaque than `.glassEffect` and is itself accessibility-aware. If a future call site drops `.bordered`, the fallback at that one site silently becomes "no background at all" — the smolspec and tasks.md both flag this dependency.+- **Test invariant choice**: the test asserts `surface1.alpha == 1` per theme using `ContrastChecker.alphaComponent(_:)`. The shared helper resolves through `UIColor(color).getRed(...)` on iOS and `NSColor(color).usingColorSpace(.sRGB)` on macOS, falling back to all-zeroes when sRGB conversion fails (intentional — callers see "fully unset" rather than a partially-valid colour and fail the assertion explicitly). Per-theme tests on `Color.secondarySystemBackground` for both `ClassicLightColors` and `ClassicDarkColors` resolve against the test runner's current trait, not the dark variant specifically. This is acceptable: the regression class the test is designed to catch (`let surface1 = Color.x.opacity(0.5)`) surfaces in either trait. Trait-specific resolution would be over-engineering for the static-modification class the test guards against.++### Architecture Impact+- **Modifier pattern as template**: the file follows the same "ViewModifier + extension View" shape as `prism/Theme/ThemedBackground.swift`. Future a11y-environment-aware modifiers (e.g. `accessibilityContrast` for finding H5 / T-1045) should follow the same pattern. The new file is named generically enough (`AdaptiveMaterial.swift`) that adding a sibling `AdaptiveContrast` modifier wouldn't require renaming.+- **Out-of-scope sites flagged**: the smolspec enumerates `CompactBottomToolbar.swift:75`, `MermaidDiagramWindow.swift:226`, `prismApp.swift:374` (download-progress overlay), and four `.fill(.ultraThinMaterial)` note views as discovered-but-deferred. A follow-up Transit ticket should pick them up so the audit's "popover/overlay surfaces" coverage stays consistent.+- **`image-detail` window theme fix as collateral**: third-party callers don't see this — the only observable change is "the image-detail window now matches the user's selected theme." Acceptable, but worth noting in the CHANGELOG (which it is).++### Potential Issues+- **Runtime toggle UX**: SwiftUI re-publishes the environment when the OS Reduce Transparency setting changes mid-session, so the surface swap is instant. No animation is wired in. If a future UX concern arises, the fix is to wrap the modifier body in `.animation(.default, value: reduceTransparency)`.+- **`make test-quick` flakiness**: this worktree's `make test-quick` is currently broken at the harness level (~2900 tests fail in the full run, all suites — including the existing WCAGContrast tests that haven't been touched). The new tests pass when run in isolation via `xcodebuild test -only-testing:prismTests/AdaptiveMaterialTests`. The harness issue is documented in agent memory and is unrelated to this change.+- **Hidden translucent surfaces**: any future contributor adding `.background(.regularMaterial, ...)` or `.glassEffect(...)` at a new overlay site will silently bypass the a11y fix. There's no linter for this. The decision log captures the rule; future work could add a custom SwiftLint rule that flags raw `.regularMaterial` outside `AdaptiveMaterial.swift`.++---++## Completeness Assessment++**Fully implemented** — every spec requirement is met:++- ✅ Reads `@Environment(\.accessibilityReduceTransparency)` and replaces `regularMaterial` with opaque `themeColors.surface1`+- ✅ Drops `.glassEffect(.regular.interactive())` to pass-through under Reduce Transparency+- ✅ No visual regression when the setting is off (verified by code structure — the `else` branch is the original call)+- ✅ Three reusable `View` extension entry points; call sites change by one line+- ✅ All 12 call sites listed in the smolspec table swapped+- ✅ `themeColors` available at every call site — `image-detail` `WindowGroup` gets `.applyTheme(...)`+- ✅ Works on iOS 26 and macOS 26 (verified by `make build-ios` and `make build-macos` both succeeding with zero warnings)+- ✅ Shape arguments preserved at every call site+- ✅ `surface1` opacity invariant tested for all 5 concrete themes+- ✅ Tests reuse `ContrastChecker` cross-platform colour-component bridge (`alphaComponent(_:)` sibling) instead of duplicating+- ✅ Decision log captures the three non-trivial decisions+- ✅ CHANGELOG entry added under `[Unreleased] / ### Added`++**Partially implemented**:++- ⚠️ Task 4 (visual a11y sweep on both platforms × 5 themes × Reduce Transparency on/off) is intentionally unchecked in `tasks.md` — it requires manual device verification and can't be automated. Code is correct and lint/build are clean; the manual sweep happens before merge.++**Not implemented (out of scope per spec)**:++- 🚫 Other accessibility audit findings (H1, H2, H3, H5, M1–M5, L1+) — separate tickets+- 🚫 High-contrast theme variant (H5 / T-1045) — separate ticket+- 🚫 Translucent surfaces the audit missed (`CompactBottomToolbar`, `MermaidDiagramWindow`, download-progress overlay, `.fill(.ultraThinMaterial)` note views) — follow-up ticket per smolspec "Out of Scope"+- 🚫 Snapshot/XCUITest harness for visual a11y regressions — separate multi-day project+- 🚫 Animated transition when toggling Reduce Transparency at runtime — UX decision separate from H4++**Validation findings**:++- No spec requirement could not be cleanly explained.+- No gaps or contradictions surfaced during the explanation.+- The implementation matches the smolspec's "Implementation Approach" line for line.

diff --git a/specs/reduce-transparency-a11y/tasks.md b/specs/reduce-transparency-a11y/tasks.mdnew file mode 100644index 0000000..3a1b2c7--- /dev/null+++ b/specs/reduce-transparency-a11y/tasks.md@@ -0,0 +1,30 @@+# Reduce Transparency a11y (T-1044)++- [x] 1. Adaptive material modifier exists with verified opaque fallback+  - Reference: specs/reduce-transparency-a11y/smolspec.md+  - Add `prism/Theme/AdaptiveMaterial.swift` containing two view modifiers — `AdaptiveMaterialBackground<S: Shape>` and `AdaptiveGlassEffect` — that read `@Environment(\.accessibilityReduceTransparency)` and `@Environment(\.themeColors)`. Use a `@ViewBuilder` body in each modifier so the two branches can return different opaque `View` types (`.background(material, in:)` vs `.background(colors.surface1, in:)`).+  - `AdaptiveGlassEffect`: when `reduceTransparency` is `true`, return `content` unchanged (no `glassEffect`, no surface paint) — the underlying `.buttonStyle(.bordered)` at every call site already renders an opaque background. Do NOT paint a `Capsule()` underneath; that guesses the system's private shape and risks platform-divergent rendering.+  - `AdaptiveMaterialBackground`: when `reduceTransparency` is `true`, paint `colors.surface1` in the provided shape. The shape-less overload passes `Rectangle()` to match the implicit default `.background(material)` uses today.+  - Expose three `View` extensions: `adaptiveMaterialBackground(_:)`, `adaptiveMaterialBackground(_:in:)`, and `adaptiveGlassEffect()`.+  - Add `prismTests/AdaptiveMaterialTests.swift` (Swift Testing) covering: (a) `surface1.cgColor?.alpha == 1` for every concrete theme (`PrismLightColors`, `PrismDarkColors`, `ClassicLightColors`, `ClassicDarkColors`, `RefractionColors`) — this is the regression that matters; (b) if a static `resolvedFallback(reduceTransparency:colors:) -> Color?` helper is extracted, assert `nil` when `false` and `colors.surface1` when `true` for both light and dark themes. If no such helper exists, drop assertion (b).+  - Verify: `make test-quick` passes; the new tests run.++- [x] 2. All regularMaterial backgrounds adapt to Reduce Transparency+  - Reference: specs/reduce-transparency-a11y/smolspec.md+  - Add `.applyTheme(settings: settings, systemObserver: systemColorSchemeObserver)` to the `image-detail` `WindowGroup` in `prism/prismApp.swift:208` (after the existing `.environment(...)` chain). This is currently the only `WindowGroup` in the app that does NOT apply `ThemeModifier`; the new modifier needs `themeColors` in scope to render correctly under dark mode.+  - Replace `.background(.regularMaterial[, in: <shape>])` with `.adaptiveMaterialBackground(...)` at each call site listed in the smolspec table: `MetadataView.swift:50`, `Search/InlineSearchBar.swift:60`, `ToastNotification.swift:36`, `ReloadBanner.swift:53`, `FootnotePopoverView.swift:61` (inside the existing `#if os(macOS)` branch), `NotePopover.swift:85`, and `ImageDetailWindow.swift:234`. Preserve each existing shape argument.+  - Verify: `make lint` produces no new warnings; `make build-ios` and `make build-macos` both succeed with zero warnings.++- [x] 3. All glassEffect call sites pass through under Reduce Transparency+  - Reference: specs/reduce-transparency-a11y/smolspec.md+  - Replace `.glassEffect(.regular.interactive())` with `.adaptiveGlassEffect()` at every call site listed in the smolspec: `MermaidPreviewCard.swift:178` and `:187`; `AccessibleTableView.swift:258`; `ImageBlockView.swift:233` and `:243` (included because the file says its overlay is kept in sync with MermaidPreviewCard).+  - Preserve the existing `.buttonStyle(.bordered)` immediately above each replacement — the bordered button is what provides the opaque background when `glassEffect` is suppressed.+  - Verify: `make lint`, `make build-ios`, and `make build-macos` all succeed with zero warnings.++- [ ] 4. Full test suite passes and Reduce Transparency renders opaque on both platforms across all themes+  - Reference: specs/reduce-transparency-a11y/smolspec.md+  - Run `make test` (iOS unit + UI tests) and `make test-quick` (macOS unit tests) — both must pass with no new failures.+  - Visually verify on iOS Simulator with Reduce Transparency ON (Settings → Accessibility → Display & Text Size → Reduce Transparency): open a document and confirm metadata header, reload banner, footnote popover, note popover, toast notification, search bar, image-detail sheet, and mermaid/image overlay buttons all render with an opaque surface. Repeat for each of: PrismLight, PrismDark, Classic (light + dark), Refraction.+  - Visually verify on macOS with Reduce Transparency ON (System Settings → Accessibility → Display → Reduce Transparency): repeat the same sweep, including the macOS-only branch of FootnotePopoverView, the macOS-only ImageDetailWindow, and the AccessibleTableView toggle button.+  - Confirm with Reduce Transparency OFF that every site still renders the original `regularMaterial` / `glassEffect` treatment unchanged.+  - Confirm the `image-detail` window now renders in the user's active theme (previously fell back to light-mode default because it didn't apply `ThemeModifier`).