Accessibility
Website Calculator Accessibility Checklist: 18 Release Tests
A reusable WCAG 2.2-oriented QA sheet for calculator inputs, validation, dynamic results, keyboard operation, touch targets and embeds.
Direct answer
A calculator passes the basic release gate when every control has a persistent programmatic label, instructions and errors are associated with the right field, the whole task works by keyboard, dynamic results are announced without disrupting focus, color is not the only signal, targets meet WCAG 2.2 sizing rules, and the layout reflows without two-dimensional scrolling.
Definition
An accessible website calculator lets people understand inputs, enter values, correct errors and receive the result using different input methods and assistive technologies. Accessibility applies to the complete task, not just the form's first screen.
Key findings
Verified 24 August 2026
- The result state is part of the form and needs an accessible name, clear units and an appropriate announcement strategy.
- Placeholder text is not a substitute for a persistent label or instruction.
- WCAG 2.2 Level AA sets a 24 by 24 CSS pixel minimum target rule with stated exceptions; larger controls remain easier to use.
- Automated scans cannot verify formula meaning, focus order through conditional steps or whether a result announcement is useful.
What should be tested before calculation?
Run these checks on the real published calculator, including the host page when it is embedded. Save the URL, viewport, browser, keyboard sequence, assistive technology if used, result and screenshot or recording for every failure.
| # | Test | Pass evidence | Primary mapping |
|---|---|---|---|
| 1 | Page and calculator have descriptive headings | Heading outline explains the task | WCAG 2.4.6 |
| 2 | Every control has a persistent label | Accessible name matches visible purpose | WCAG 1.3.1, 3.3.2, 4.1.2 |
| 3 | Units and formats are explicit | Currency, period and valid range remain visible | WCAG 3.3.2 |
| 4 | Related choices are grouped | Fieldset and legend or equivalent relationship exists | WCAG 1.3.1 |
| 5 | Required status is conveyed | Not dependent on color or a symbol alone | WCAG 1.3.1, 3.3.2 |
| 6 | Autocomplete and input purpose are appropriate | Browser and assistive technology receive the intended purpose | WCAG 1.3.5 |
How should keyboard and pointer operation be tested?
Start with the pointer disconnected. Tab from the page address bar through the calculator, change every control, activate Calculate, reach the result and continue to the next action. Reverse with Shift+Tab. Focus must remain visible, logical and unobscured.
| # | Test | Pass evidence | Primary mapping |
|---|---|---|---|
| 7 | Complete task by keyboard | No mouse-only slider, tooltip or submit action | WCAG 2.1.1 |
| 8 | Focus order follows the task | Conditional fields enter the sequence where expected | WCAG 2.4.3 |
| 9 | Focus is visible and not obscured | Indicator remains visible under headers and dialogs | WCAG 2.4.7, 2.4.11 |
| 10 | Targets meet size or spacing rule | At least 24 by 24 CSS pixels or a documented exception | WCAG 2.5.8 |
How should errors and results behave?
Test a missing required value, a non-number, the lower and upper boundary, and a conflicting combination. The error needs plain-language text, programmatic association and a correction route. Do not erase valid entries after another field fails.
Then calculate a valid result and change one input. The result should identify its value, unit, time period and relevant assumption. Use a polite live region for a concise update when appropriate; avoid announcing every keystroke in a long formula.
| # | Test | Pass evidence | Primary mapping |
|---|---|---|---|
| 11 | Invalid fields are identified | Error text names the field and problem | WCAG 3.3.1 |
| 12 | Correction is suggested | Accepted range or format is stated | WCAG 3.3.3 |
| 13 | Errors are programmatically connected | aria-describedby or equivalent relationship works | WCAG 1.3.1, 4.1.2 |
| 14 | Dynamic result is communicated | A concise update is announced without moving focus unexpectedly | WCAG 4.1.3 |
| 15 | Meaning does not rely on color | Text and values explain positive, neutral or negative states | WCAG 1.4.1 |
What layout and embed tests remain?
Zoom text to 200%, test a 320 CSS pixel viewport and inspect both the host page and calculator document. Tables may scroll within a labeled region, but the primary calculation flow should not require simultaneous horizontal and vertical scrolling.
| # | Test | Pass evidence | Primary mapping |
|---|---|---|---|
| 16 | Text resizes and content reflows | No lost controls or clipped result at zoom and narrow width | WCAG 1.4.4, 1.4.10 |
| 17 | Motion is avoidable | Reduced-motion preference removes nonessential transitions | WCAG 2.3.3 |
| 18 | Embedded context is named and escapable | iframe title is useful and focus does not become trapped | WCAG 2.1.2, 4.1.2 |
What does this checklist not prove?
Passing these checks is not a certification or legal opinion. It does not replace testing with disabled users, a broader WCAG conformance evaluation or review of the surrounding product journey. Treat the sheet as a repeatable release gate and retain failures as work items rather than averaging them into a score.
Method and evidence
Evidence type: 18-test WCAG mapping and manual QA decision sheet
- Mapped calculator states to W3C forms guidance and relevant WCAG 2.2 criteria.
- Separated automatically detectable checks from keyboard, screen-reader and cognitive checks that require human judgment.
- Covered the empty state, invalid state, calculated result, conditional branch and embedded context.
- Defined pass evidence so a reviewer can reproduce the decision instead of recording only a score.
Topic score: 4.68 / 5. Business fit 4.5, verified demand 4, distinct intent 5, original evidence 5, citation usefulness 5, feasibility 5.
Primary sources
- W3C WCAG 2.2 Understanding ↗Primary success-criterion explanations, updated February 2026.
- W3C Forms Tutorial ↗Primary form labeling, grouping, instruction and feedback guidance.
- W3C Target Size Minimum ↗Level AA 24 by 24 CSS pixel rule and exceptions.
- MDN iframe accessibility ↗Current guidance for naming embedded frames.
Limitations
- The checklist is a release aid, not a claim of WCAG conformance or legal compliance.
- Assistive-technology behavior varies by browser and platform, so representative combinations still need direct testing.
Verification and corrections
Checklist mapping to current W3C guidance verified 24 August 2026.
Recommended retest: Retest before every calculator release and after changes to fields, logic, results, charts or embeds.
Found an error or a changed standard? Use the correction process and include the page URL and primary evidence.
Next step
Apply the evidence to your next release
Use the published method, keep a dated test record and revisit the result after the calculator or its operating rules change.
Open the testing protocol