UIST Camera-Ready
A UIST acceptance is conditional: the June 27 notification (2026 cycle, verified
2026-07-08) accepts the paper as amended by your rebuttal, and the July 24
camera-ready is where those amendments come due. This phase has three workstreams —
the contractual edits, the ACM production pipeline with its accessibility
requirements, and conference logistics — and they share four weeks.
Workstream 1: deliver the contract
Reconstruct the promise ledger from your rebuttal (see uist-author-response) and
the meta-review or condition list in the notification:
- Make each promised change where you said you would make it, and keep a diff-notes
file mapping promise → location — useful if the process asks anyone to verify
conditions, and essential when six co-authors edit in parallel.
- The growth budget is +10%: one extra page for standard papers, half a page for
short papers (2026 numbers). Promised additions get the space first; new
camera-ready ambitions get what remains.
- Do not silently make substantive changes nobody asked for; a camera-ready is a
fulfillment step, not a second revision cycle.
Workstream 2: production and accessibility
Camera-ready flows through ACM TAPS (source upload, not just a PDF), and the
2026 guide adds accessible-PDF tagging via APTARA. The author-side accessibility
obligations are concrete:
| Item |
2026 requirement |
| Alt text |
Required for every figure, subfigure, and table |
| Tables |
Real table markup, not images of tables |
| Math |
Source-level math, not equation screenshots |
| Video |
Final video figure with captions |
| PDF tagging |
Applied in the TAPS/APTARA workflow from your source |
Writing alt text for an interface-systems paper is its own small craft: describe
the interaction state the figure evidences, not the pixels. "Annotated sequence:
a finger drags on the forearm and the cursor traces the same path on the watch,
0.3 s later" beats "screenshot of the system."
Alt-text pass over the figure inventory:
[ ] every \includegraphics has \Description{...}
[ ] every subfigure has its own description
[ ] tables described (what varies across rows/columns, the takeaway)
[ ] teaser figure description states the core interaction
[ ] no description says "image of" / "figure showing" boilerplate
Workstream 3: de-anonymize and finalize assets
- Restore authors, affiliations, acknowledgements, and grant numbers; flip the
acmart options from the review/anonymous configuration to the final one per the
current guide.
- Reverse the third-person self-citation contortions where they now read oddly —
but only where the meaning improves.
- Restore real repository and project-page URLs, and make them live before the
proceedings do (see
uist-artifact-evaluation for what should be at the other
end).
- Produce the final video figure: captioned, de-anonymized, credits added; check
the current guide for any preview-video obligation (待核实 for 2026).
- Complete ACM e-rights before TAPS will process; the open-access terms applying to
UIST 2026 authors were not verifiable at check time (待核实) — read the e-rights
form, not folklore.
TAPS realities
TAPS consumes source (LaTeX or Word), not a hand-tuned PDF, which surprises teams
whose submission compiled through local hacks:
- Custom macros, non-standard packages, and manual float surgery that survived
review can fail TAPS validation; budget one full rebuild-from-clean-template
day.
- Figures need production-quality originals (vector where possible); the
screenshot that looked fine at review DPI may not at publication.
- The
\Description{} commands are part of the source, so the alt-text pass
happens in LaTeX, not in a PDF editor afterward.
- Validate early: upload a candidate build the week the system opens rather than
on the deadline, because TAPS error messages arrive on production timelines,
not chat timelines.
- Keep the review PDF and the camera-ready in the same repository with a tagged
divergence point; the "which version did we promise that in" question recurs
for years.
Four-week schedule (notification June 27 → deadline July 24, 2026)
| Week |
Deliverable |
| 1 |
Promise ledger reconstructed; edits assigned; e-rights initiated; registration/visa checks started |
| 2 |
All contractual edits merged; +10% budget reconciled; figure originals collected |
| 3 |
Alt-text pass; TAPS candidate upload; validation errors cleared |
| 4 |
Final video captioned and uploaded; last TAPS build verified; buffer only |
Conference logistics start now
- Registration and the presenting author: confirm the current in-person requirement
wording (待核实 for 2026) as soon as notification lands — visas for a US venue
(Detroit, November 2-5, 2026) can take longer than the camera-ready window.
- UIST talks are short and demo-culture shaped: build the talk around the live or
recorded demonstration, not around related-work slides.
- Plan the hallway demo: papers whose systems can be demonstrated at the conference
compound their impact; shipping hardware to a venue takes lead time (and consider
a Demos-track submission for the same system where the rules allow).
Output format
[Contract status] promises delivered <k>/<n>; open items with owners
[Page budget] final length vs +10% allowance
[TAPS status] source uploaded / validation errors / complete
[Accessibility] alt-text pass done? tables/math as markup? video captioned?
[Logistics] e-rights · registration · visa · demo shipping — each with a date
Source: brycewang-stanford/Awesome-Journal-Skills → UIST-Skills/skills/uist-camera-ready/SKILL.md
1---2name: uist-camera-ready3description: Use when converting a conditional UIST acceptance into a published paper — delivering the rebuttal-promised changes by the July deadline, working the ACM TAPS pipeline with alt text for every figure and table, de-anonymizing correctly, finalizing the video figure, and preparing the Detroit talk and demo.4---5
6
7# UIST Camera-Ready
8
9A UIST acceptance is conditional: the June 27 notification (2026 cycle, verified
102026-07-08) accepts the paper *as amended by your rebuttal*, and the July 24
11camera-ready is where those amendments come due. This phase has three workstreams —
12the contractual edits, the ACM production pipeline with its accessibility
13requirements, and conference logistics — and they share four weeks.
14
15## Workstream 1: deliver the contract
16
17Reconstruct the promise ledger from your rebuttal (see `uist-author-response`) and
18the meta-review or condition list in the notification:
19
20- Make each promised change where you said you would make it, and keep a diff-notes
21 file mapping promise → location — useful if the process asks anyone to verify
22 conditions, and essential when six co-authors edit in parallel.
23- The growth budget is +10%: one extra page for standard papers, half a page for
24 short papers (2026 numbers). Promised additions get the space first; new
25 camera-ready ambitions get what remains.
26- Do not silently make substantive changes nobody asked for; a camera-ready is a
27 fulfillment step, not a second revision cycle.
28
29## Workstream 2: production and accessibility
30
31Camera-ready flows through **ACM TAPS** (source upload, not just a PDF), and the
322026 guide adds accessible-PDF tagging via APTARA. The author-side accessibility
33obligations are concrete:
34
35| Item | 2026 requirement |
36|---|---|
37| Alt text | Required for **every figure, subfigure, and table** |
38| Tables | Real table markup, not images of tables |
39| Math | Source-level math, not equation screenshots |
40| Video | Final video figure with captions |
41| PDF tagging | Applied in the TAPS/APTARA workflow from your source |
42
43Writing alt text for an interface-systems paper is its own small craft: describe
44the interaction state the figure evidences, not the pixels. "Annotated sequence:
45a finger drags on the forearm and the cursor traces the same path on the watch,
460.3 s later" beats "screenshot of the system."
47
48```text
49Alt-text pass over the figure inventory:
50 [ ] every \includegraphics has \Description{...}
51 [ ] every subfigure has its own description
52 [ ] tables described (what varies across rows/columns, the takeaway)
53 [ ] teaser figure description states the core interaction
54 [ ] no description says "image of" / "figure showing" boilerplate
55```
56
57## Workstream 3: de-anonymize and finalize assets
58
59- Restore authors, affiliations, acknowledgements, and grant numbers; flip the
60 `acmart` options from the review/anonymous configuration to the final one per the
61 current guide.
62- Reverse the third-person self-citation contortions where they now read oddly —
63 but only where the meaning improves.
64- Restore real repository and project-page URLs, and make them live before the
65 proceedings do (see `uist-artifact-evaluation` for what should be at the other
66 end).
67- Produce the final video figure: captioned, de-anonymized, credits added; check
68 the current guide for any preview-video obligation (待核实 for 2026).
69- Complete ACM e-rights before TAPS will process; the open-access terms applying to
70 UIST 2026 authors were not verifiable at check time (待核实) — read the e-rights
71 form, not folklore.
72
73## TAPS realities
74
75TAPS consumes source (LaTeX or Word), not a hand-tuned PDF, which surprises teams
76whose submission compiled through local hacks:
77
78- Custom macros, non-standard packages, and manual float surgery that survived
79 review can fail TAPS validation; budget one full rebuild-from-clean-template
80 day.
81- Figures need production-quality originals (vector where possible); the
82 screenshot that looked fine at review DPI may not at publication.
83- The `\Description{}` commands are part of the source, so the alt-text pass
84 happens in LaTeX, not in a PDF editor afterward.
85- Validate early: upload a candidate build the week the system opens rather than
86 on the deadline, because TAPS error messages arrive on production timelines,
87 not chat timelines.
88- Keep the review PDF and the camera-ready in the same repository with a tagged
89 divergence point; the "which version did we promise that in" question recurs
90 for years.
91
92## Four-week schedule (notification June 27 → deadline July 24, 2026)
93
94| Week | Deliverable |
95|---|---|
96| 1 | Promise ledger reconstructed; edits assigned; e-rights initiated; registration/visa checks started |
97| 2 | All contractual edits merged; +10% budget reconciled; figure originals collected |
98| 3 | Alt-text pass; TAPS candidate upload; validation errors cleared |
99| 4 | Final video captioned and uploaded; last TAPS build verified; buffer only |
100
101## Conference logistics start now
102
103- Registration and the presenting author: confirm the current in-person requirement
104 wording (待核实 for 2026) as soon as notification lands — visas for a US venue
105 (Detroit, November 2-5, 2026) can take longer than the camera-ready window.
106- UIST talks are short and demo-culture shaped: build the talk around the live or
107 recorded demonstration, not around related-work slides.
108- Plan the hallway demo: papers whose systems can be demonstrated at the conference
109 compound their impact; shipping hardware to a venue takes lead time (and consider
110 a Demos-track submission for the same system where the rules allow).
111
112## Output format
113
114```text
115[Contract status] promises delivered <k>/<n>; open items with owners
116[Page budget] final length vs +10% allowance
117[TAPS status] source uploaded / validation errors / complete
118[Accessibility] alt-text pass done? tables/math as markup? video captioned?
119[Logistics] e-rights · registration · visa · demo shipping — each with a date
120```
121
122---
123
124**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `UIST-Skills/skills/uist-camera-ready/SKILL.md`
thedixitjain