docs: add accessibility guidance

Add accessibility guidance, an accessibility issue template, and a PR checklist for open-source accessibility practices.

Author: ftchvs

.github/ISSUE_TEMPLATE/accessibility.yml

@@ -0,0 +1,34 @@
+name: Accessibility issue
+description: Report a barrier in the CLI, reports, docs, API docs, or Web UI.
+title: "[Accessibility]: "
+labels: ["accessibility"]
+body:
+  - type: textarea
+    id: barrier
+    attributes:
+      label: Accessibility barrier
+      description: What was difficult or impossible to use?
+    validations:
+      required: true
+  - type: textarea
+    id: surface
+    attributes:
+      label: Surface
+      description: CLI command, report, API page, Web UI screen, or documentation page.
+    validations:
+      required: true
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: Browser, terminal, operating system, screen reader, keyboard-only use, or other setup.
+  - type: textarea
+    id: sample
+    attributes:
+      label: Safe sample
+      description: Minimal synthetic sample input or output. Do not include private ad copy or customer data.
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+      description: What would make this accessible?

.github/pull_request_template.md

@@ -0,0 +1,13 @@
+## Summary
+
+-
+
+## Checks
+
+- [ ] I ran relevant tests or documented why not.
+- [ ] I added or updated tests/eval rows for behavior changes.
+- [ ] I preserved decision-support and legal-boundary language.
+- [ ] I avoided adding private data, secrets, or raw real ad submissions.
+- [ ] I checked keyboard navigation, labels, visible focus, and color-independent status in UI changes.
+- [ ] I kept CLI and report output understandable without relying on color alone.
+- [ ] I updated docs if the user-facing behavior changed.

ACCESSIBILITY.md

@@ -0,0 +1,36 @@
+# Accessibility
+
+AdLint includes a CLI, FastAPI service, reports, documentation, and a local Web
+UI. Accessibility work in this repo focuses on making policy review usable for
+keyboard-only users, screen reader users, low-vision users, and users who rely on
+structured output.
+
+## What we aim for
+
+- CLI output remains useful without color and supports JSON for automation.
+- Markdown reports use clear headings, tables, and descriptive links.
+- The local Web UI supports keyboard navigation and visible focus states.
+- Form fields have labels, descriptions, and useful error messages.
+- Review decisions do not depend on color alone.
+- Screenshots and docs include meaningful alt text.
+- Motion or loading states avoid creating barriers.
+
+## Reporting accessibility issues
+
+Please open an accessibility issue if you find:
+
+- unlabeled form controls or confusing focus order
+- color-only severity or decision indicators
+- reports that are hard to navigate with assistive technology
+- CLI output that cannot be understood without color
+- screenshots or docs without useful text alternatives
+
+Include the command, page, browser, terminal, operating system, assistive
+technology, and sample input when relevant. Do not include private ad copy,
+customer data, credentials, or raw real submissions.
+
+## Contribution expectations
+
+UI changes should include a keyboard pass, visible-focus check, and
+color-independent review of severity/status indicators. CLI/report changes
+should preserve structured output and readable text output.

CONTRIBUTING.md

@@ -74,10 +74,19 @@ AdLint should remain privacy-conscious:
 - Do not claim legal compliance, guaranteed platform approval, or definitive statutory determinations.
 - Keep local model features as decision support unless benchmarked evidence proves otherwise.
 
+## Accessibility expectations
+
+- Keep CLI output understandable without color alone.
+- Preserve JSON output for users who need structured or automated review.
+- Label Web UI form controls and keep keyboard focus visible.
+- Do not communicate severity, status, or risk only through color.
+- Add useful alt text for screenshots and diagrams.
+
 ## Pull request checklist
 
 - [ ] I ran relevant tests or documented why not.
 - [ ] I added/updated tests or eval rows for behavior changes.
 - [ ] I preserved decision-support and legal-boundary language.
 - [ ] I avoided adding private data, secrets, or raw real ad submissions.
+- [ ] I checked relevant accessibility expectations from [ACCESSIBILITY.md](ACCESSIBILITY.md).
 - [ ] I updated docs if the user-facing behavior changed.

README.md

@@ -579,6 +579,11 @@ High-value contribution areas:
 - Safer rewrite-quality evaluation.
 - Docs, examples, screenshots, and launch polish.
 
+## Accessibility
+
+Accessibility expectations for the CLI, reports, docs, and local Web UI are in
+[ACCESSIBILITY.md](ACCESSIBILITY.md).
+
 ## Related docs
 
 - `docs/open_source_goal.md`