Mac UI color accessibility checklist before handoff
Color accessibility is easier to fix while the UI is still on your Mac. Sample the rendered state, name the color role, export the palette, check contrast, and document the edge cases before review.
A practical Mac UI color accessibility checklist starts with the rendered screen. Pick the actual color, decide what role it plays, test the foreground and background pair, then write down the state you checked.
Do this before handoff. It prevents vague review comments like "the blue looks low contrast" and gives the next person a useful note: button label #FFFFFF on button fill #0A66C2, default state, AA normal text pass.
Disclosure: I build TeenyApps, including TeenyColor and TeenyTool. My bias is toward local Mac checks for private UI work. The checklist below is still conservative: a local tool can catch color mistakes, but it does not replace a full accessibility audit.
Quick answer
| Handoff question | Local Mac check | Record in the handoff |
|---|---|---|
| Which color did we actually render? | Sample the pixel from the app, browser, screenshot, or prototype state. | Color value, source screen, and whether the value came from render or design token. |
| What is the color for? | Name its role before exporting it: text, background, border, icon, state, chart, or focus ring. | Role name, state, dark/light mode, and any token name you know. |
| Can people read it? | Check the exact foreground and background pair against WCAG thresholds. | Contrast ratio, AA/AAA result, text size assumption, and state tested. |
| Does the non-text UI still work? | Check meaningful borders, icons, focus indicators, and chart marks separately. | Component name, contrast pair, and whether color is the only signal. |
01Sample the rendered state first
A design token is useful, but the rendered UI is what users see. Browser zoom, opacity, antialiasing, image backgrounds, dark mode, disabled states, and inherited styles can change the color that lands on screen.
Sample the rendered state when the question is "what color did this screen show?" Sample the design source when the question is "what token should this component use?" If those answers differ, document the difference instead of quietly picking one.
TeenyColor uses the native macOS color sampler, converts sampled colors to sRGB, copies the selected format to the pasteboard, keeps local history, supports pinned colors, and can export palettes. That makes it useful when a QA pass involves more than one color.
02Name the role before exporting a palette
A palette full of unlabeled swatches is not a handoff. It is a pile of numbers. Name the role while the UI state is still fresh: primary button fill, primary button label, focus ring, card border, muted label, warning background, chart line, selected row, disabled text.
That naming step keeps the palette honest. If a sampled hover color is only valid in one state, do not export it as if it were the main brand blue. If a screenshot value came from an antialiased text edge, do not treat it as the text color.
The TeenyColor source supports custom names, pinned colors, local history, and palette export as text or JSON. The deeper spoke for this workflow is exporting a color palette from picked Mac colors.
03Check the exact foreground and background
Most contrast misses are input mistakes. Someone checks text against white when the real background is a tinted card. Someone tests default text but ships disabled text. Someone samples the edge of antialiased type instead of the actual CSS color.
WCAG 2.2 Success Criterion 1.4.3 sets the Level AA minimum at 4.5:1 for normal text and 3:1 for large text. AAA targets are higher. Non-text contrast is a separate criterion for meaningful UI components and graphical objects.
TeenyTool includes a local Contrast Checker. Its source converts hex colors to RGB, linearizes channels, calculates relative luminance, and reports the standard contrast ratio. The matching spoke for threshold decisions is WCAG contrast ratios on Mac.
04Do not stop at the first pass
A 4.51:1 result is technically different from 4.49:1, but it is still a fragile design choice. Thin fonts, antialiasing, display differences, image backgrounds, and later edits can erase a borderline pass.
If a text pair barely passes, improve it before handoff. If a focus ring, icon, or border carries meaning, check it as non-text UI. If color is the only difference between success and error, add text, shape, position, or another visible cue.
This is where the checklist becomes useful. It gives reviewers a record of what was tested and makes the next decision smaller: adjust the token, document the exception, or escalate to a broader accessibility review.
05Keep private UI work local until it belongs somewhere else
Color accessibility checks often start from private material: unreleased UI, client dashboards, product screenshots, internal admin screens, design tokens, or bug evidence. A simple color value or contrast check should not force that material through a random web tool.
Use local tools for first-pass sampling, palette export, format conversion, and contrast checks. Upload or paste the final evidence only where it belongs: a design file, code review, issue tracker, accessibility report, or shared handoff doc.
The broader privacy rule is in local Mac utilities vs online tools. The color-specific version is simple: keep screenshots and tokens on your Mac unless collaboration is the reason to move them.
Handoff checklist
- Open the UI state you plan to hand off: default, hover, focus, disabled, error, selected, light mode, or dark mode.
- Sample the rendered foreground and background colors from the actual screen or screenshot.
- Name each color role before exporting or copying values.
- Export a short palette only after duplicate, accidental, and antialiased samples are removed.
- Check normal text, large text, buttons, links, labels, icons, focus rings, and meaningful borders.
- Write down the contrast ratio, AA/AAA result, and the state tested.
- Escalate anything borderline, image-backed, gradient-backed, or color-only to deeper review.
What each tool should do
| Tool | Best job | Do not use it for |
|---|---|---|
| TeenyColor | Sampling rendered colors, naming picks, pinning important swatches, exporting small palettes. | Declaring a full design-system token model. |
| TeenyTool | Checking foreground/background contrast, converting nearby color values, handling quick utility work. | Replacing semantic, keyboard, focus-order, or assistive technology testing. |
| Design file | Owning tokens, component specs, usage rules, and shared visual decisions. | Proving what the final rendered screen actually showed. |
| Accessibility audit | Testing the full experience across markup, keyboard, focus, content, states, and assistive tech. | Solving every small pre-handoff color typo. |
Sources checked
- TeenyColor claims were checked against the TeenyColor homepage and local Swift source for native color sampling, sRGB conversion, pasteboard copy, local history, pinned colors, custom names, and palette export.
- TeenyTool claims were checked against the TeenyTool homepage and local Swift source for color conversion, contrast calculation, and color utility coverage.
- W3C WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum).
- W3C WCAG 2.2 Success Criterion 1.4.11 Non-text Contrast.
- Apple Support: Digital Color Meter User Guide for Mac.
FAQ
What should a Mac UI color accessibility checklist include?
It should include rendered color sampling, role naming, palette export, normal-text contrast, large-text contrast, non-text contrast, dark mode, hover, focus, disabled states, and a note about the source of truth for every color.
Should designers check contrast before handoff?
Yes. A designer or front-end reviewer should catch obvious foreground and background failures before handoff, then leave deeper assistive technology testing for the full accessibility pass.
Can a local Mac tool replace a full accessibility audit?
No. A local Mac tool is useful for first-pass color and contrast checks. A full accessibility audit still needs semantic markup, keyboard behavior, focus order, assistive technology checks, and real content states.
Check color before handoff.
Use TeenyColor to sample and export UI colors. Use TeenyTool to check the contrast pair and handle the nearby utility work locally.