A colour pair can look clear on one bright screen and become unreadable on a low-cost phone outdoors. Contrast testing turns that visual opinion into a repeatable check.
Test the exact foreground and background values used in the interface, classify the text size correctly, and verify states such as hover, disabled, focus and error separately.
WCAG Contrast Checker opens the practical workflow in your browser.
Practical answer
Start with the receiving decision, not the calculator. Write down who will use the result, which document or workflow it supports, the date it is needed and the rule that decides whether it is acceptable. A technically correct number or file can still fail when it answers the wrong question, uses the wrong period or arrives in a format the recipient cannot use.
Inputs to verify
| Input | What to verify |
|---|---|
| Foreground colour | Exact CSS or design-token value |
| Background colour | The final composited background, not a nearby swatch |
| Text size and weight | Rendered size used to determine large-text treatment |
| Component state | Default, hover, focus, error, selected or disabled |
| Target standard | WCAG level and organisation acceptance rule |
Keep the source evidence beside the inputs. That may be a contract, calendar, design token, source document, account rule, style guide, price list or measurement note. Record the date and version where a rule can change. If an input is an estimate, label it as an estimate instead of presenting it as an observed fact.
Step-by-step workflow
- Copy the exact rendered foreground and background colours.
- Run the pair through the checker.
- Classify normal text, large text and non-text controls correctly.
- Test every interactive and validation state.
- Record failing pairs and replace them through shared design tokens.
Run the first result as a baseline, then change one important assumption at a time. This makes the sensitivity visible and helps another person understand why the answer moved. Do not silently adjust several inputs until the output looks convenient. Save the rejected scenario too when it explains a risk or boundary.
How to make the result dependable
Contrast alone does not make a page accessible. Keyboard access, labels, zoom, focus visibility and screen-reader semantics still need their own checks.
Transparency, gradients and background images can change the effective colour. Test the least favourable area where the text actually appears.
Brand colours can be retained for decoration while a darker or lighter accessible token handles text and controls.
Reopen every downloaded file and recalculate any high-impact result independently. Check labels, units, page order, dates, signs, rounding and the intended destination. A browser preview or successful download proves only that an action completed. It does not prove that the result is complete, accepted or suitable for the next step.
Common mistakes
- Testing a palette swatch instead of the rendered component
- Checking body text but ignoring placeholders and errors
- Using colour alone to communicate status
- Assuming a passing ratio guarantees full accessibility
Verification and decision record
Create a short decision record with the source, inputs, assumptions, result, reviewer and next action. When the situation changes, make a new dated version rather than overwriting the only record. This gives teams, students and households a practical audit trail without turning an everyday tool into a claim of official approval.
Before closing the task, compare the result with the real-world constraint it is supposed to satisfy. Ask whether a different country, institution, device, unit, document version or audience would change the answer. When two reasonable interpretations exist, record both and explain which one you selected. A good handoff includes enough context for a colleague, client, lecturer or family member to challenge the assumptions without repeating the whole exercise. If an external rule matters, reopen the official source on the day of action. If the source is unavailable or unclear, pause the irreversible step and seek confirmation rather than presenting the draft as final.
Finally, distinguish the calculation or file from the decision made with it. The output is evidence for a conversation, approval or next action. It is not the approval itself.
This guide and tool support planning and checking. They do not guarantee acceptance, compliance, profit, security, accessibility, academic marks or a particular operational outcome.
Privacy and safe use
Use the minimum personal or confidential information needed. Prefer local processing for identity, financial, employment, academic and business documents. Never place passwords, identity numbers, private contracts or raw personal records into an untrusted service. The relevant authority, institution, employer, client or qualified professional remains the final decision maker.
Open the AfroTools tool
Open the tool with the verified inputs already beside you. Complete one baseline run, name or download the result clearly, and compare it with the acceptance rule you recorded at the start. If the tool exposes optional settings, change them deliberately and document why. Keep the original source material available so a reviewer can reproduce the result without guessing which values or version you used.
Sources and further verification
Related AfroTools guides
Frequently asked questions
WCAG 2.2 Level AA specifies at least 4.5:1 for normal text, with defined exceptions. Check the current standard for your case.
Yes. WCAG defines a lower minimum for qualifying large text, so measure the actual rendered size and weight.
No. It checks a colour pair. Accessibility review covers many additional criteria and real user interaction.