Teams get confused about APCA and WCAG contrast when they expect them to answer the exact same question. They do not. WCAG contrast rules are still the formal baseline many product teams use for accessibility review, especially when checking text against the familiar 4.5:1 and 3:1 thresholds. APCA, on the other hand, is often discussed because designers and accessibility practitioners want a contrast model that better reflects perceived readability in more real-world situations. The practical takeaway for Figma teams is not "pick one and ignore the other." It is usually "know when each check is helping you make a better design decision." This matters because Waysorted’s live documentation for Palettable already positions the tool as supporting both WCAG and APCA contrast evaluation. So if a design team is already checking color inside Figma, the next useful question is how to interpret both systems without turning accessibility review into a debate club.
What WCAG contrast is still good for
WCAG contrast guidance remains the familiar standard in many teams because it is clear and widely used. The W3C’s Understanding Success Criterion 1.4.3 states that normal text should generally have a contrast ratio of at least 4.5:1, while large text can pass at 3:1. For meaningful non-text UI elements, W3C’s non-text contrast guidance points to a 3:1 minimum against adjacent colors. That makes WCAG especially useful for:
- baseline text checks
- formal accessibility review workflows
- documenting pass/fail requirements
- communicating with teams that need simple threshold language
WCAG is not obsolete just because newer discussions exist. It still gives teams a common floor.
Why APCA enters the conversation
APCA keeps coming up because accessibility work does not stop at simple pass/fail ratios. Designers often run into cases where a pair technically passes a ratio target but still feels weak in real use. In other cases, a pair that seems visually workable gets flagged under older contrast thinking in ways that feel unintuitive. That is the space where APCA gets attention. It is discussed as a more perceptual contrast approach, particularly when teams want a more nuanced understanding of readability across different text weights, sizes, and light-dark relationships. In practice, teams mention APCA when:
- designing fuller type scales
- testing subtle text treatments
- refining design system color decisions
- checking whether a pair is merely "passing" or actually comfortable to use
The key point is that APCA is often used to improve judgment, not just replace checklists.
Why checking both can be useful
For many product teams, the most practical workflow is:
- use WCAG to confirm the baseline requirement
- use APCA to stress-test the quality of the reading experience
This is especially helpful when a color pair sits near the edge of acceptability. A team may be able to say:
- WCAG says the pair clears the baseline
- APCA suggests the pair is still not ideal for the way this text is being used
That creates a better design conversation. Instead of asking only "Does it pass?" the team can ask "Is this still a strong choice?" That is a healthier workflow than arguing that one system automatically cancels the other.
Where teams get misled
Contrast review breaks down when teams:
- treat WCAG as the only signal that matters
- treat APCA as permission to ignore baseline accessibility expectations
- run one check in isolation without looking at actual component context
- assume text contrast and non-text contrast are the same problem
This is why context matters. Body text, muted labels, badges, tabs, icons, and borders all behave differently in interfaces. The most useful contrast workflow is the one that helps the team check the right thing for the right job.
Text contrast versus non-text contrast
One reason teams get tangled is that they mix text and non-text requirements into one bucket. W3C separates them for a reason. Text contrast guidance focuses on readable text and text images. Non-text contrast guidance covers meaningful UI visuals such as component boundaries, icons, graphical objects, and other visual cues that users depend on. So a good Figma review process should distinguish:
- body text readability
- large text and heading treatments
- interactive states and UI boundaries
- icon and indicator visibility
That separation makes both WCAG and APCA checks more useful, because the design team is no longer pretending every contrast decision is the same kind of decision.
A practical workflow inside Figma
If your team uses Figma for system or interface work, a good contrast routine looks like this:
Start with the real component pair
Do not test random swatches first. Test the color pair as it will actually appear:
- text on surface
- inverse text on brand fills
- icon on background
- border on card
- label on status chip
Check the WCAG baseline
For text, confirm whether the pair clears the expected threshold for the size and usage. For UI visuals, check the relevant non-text contrast baseline.
Use APCA to pressure-test the choice
If the pair barely passes or still feels questionable, use APCA as a second lens on readability quality.
Adjust the palette, not just the one screen
If the same issue keeps appearing, the problem is probably not one component. It is the palette or token system underneath it. This is why the workflow belongs inside the design system process, not only at final QA time.
Where Waysorted Palettable fits
Waysorted’s public Palettable documentation explicitly mentions real-time evaluation against both WCAG and APCA standards. That is useful because it keeps the contrast discussion close to the actual palette and interface choices instead of pushing it into a separate accessibility spreadsheet. For teams building:
- design systems
- product UI color scales
- accessible text and surface pairs
- reusable state colors
that combined checking workflow is more practical than bouncing between disconnected tools and interpretations. The point is not to overwhelm designers with two systems. It is to give them a better decision loop while they are still shaping the palette.
Common mistakes to avoid
Watch for these habits:
- using WCAG pass/fail as the entire judgment
- using APCA language without checking baseline requirements
- checking swatches but not real components
- ignoring non-text contrast in interactive UI elements
- treating near-threshold pairs as good enough just because they squeak by
Accessibility usually gets better when teams become a little less satisfied with borderline choices.
FAQ
Should I still check WCAG if I use APCA?
Yes. WCAG contrast guidance is still a common baseline for product accessibility review.
What is the point of APCA then?
APCA is often used as a more perceptual lens on readability, especially for closer judgment calls and design-system refinement.
Does APCA replace WCAG in product teams today?
In many workflows, no. Teams often use APCA alongside WCAG rather than as a full replacement.
Should I check non-text contrast separately?
Yes. W3C treats non-text contrast as its own requirement, and UI cues like borders, icons, and controls should not be folded into text checks casually.
How does Waysorted help?
Waysorted Palettable helps designers evaluate color relationships against both WCAG and APCA while working inside the design workflow. The real win is not having two contrast systems. It is learning how to use each one for the decision it is actually good at.