A conversational form can display a file picker correctly while screen reader users receive no useful announcement when an upload starts, advances, fails, is replaced, or completes. That creates duplicate submissions, abandoned forms, and files that appear attached visually but are absent from the final entry.
Use this for job applications, support requests, claims, registrations, medical intake, legal inquiries, and any Gravity Forms conversational flow where a file is required or materially affects service.
Quick answer
Test with a real keyboard and at least one desktop and one mobile screen reader. Move to the file step, choose a valid marked file, listen for filename and progress state, interrupt the upload, try an oversized file and an unsupported type, remove and replace a file, navigate away and back, then submit. Focus must remain predictable, errors must identify the file and recovery action, completion must be announced once, and the final entry must contain exactly the file the user heard confirmed.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Valid file | Small PDF | Start and completion announced |
| Too large | Over server limit | Specific recoverable error |
| Network loss | Throttle then offline | Failure announced, no ghost file |
| Replace | Same filename, new hash | New file confirmed once |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Write the expected announcement sequence | Record Gravity Forms version, conversational mode, browser, device, screen reader, zoom, language, allowed types, size limit, storage path, antivirus layer, and cache state. | Selection, upload start, progress or busy state, completion, removal, replacement, and failure are perceivable without sight. |
| Create valid and failing file fixtures | Test keyboard-only selection, drag and drop where supported, slow upload, lost network, server rejection, unsupported type, oversized file, same-name replacement, multiple files, and removal. | Keyboard focus never becomes lost or trapped after a state change. |
| Test keyboard and screen reader behavior | Inspect accessible names, live-region politeness, progress values, error association, focus after failure, focus after removal, tab order, and whether repeated announcements obscure instructions. | Client and server errors identify the same rejected file and next action. |
| Reconcile temporary and stored objects | Compare visible filename, browser request, temporary upload, stored entry, notification link, retention job, and final downloadable object using a unique harmless marker. | The final entry, notification, and storage object match the confirmed filename and checksum. |
What to check first
- Record Gravity Forms version, conversational mode, browser, device, screen reader, zoom, language, allowed types, size limit, storage path, antivirus layer, and cache state.
- Test keyboard-only selection, drag and drop where supported, slow upload, lost network, server rejection, unsupported type, oversized file, same-name replacement, multiple files, and removal.
- Inspect accessible names, live-region politeness, progress values, error association, focus after failure, focus after removal, tab order, and whether repeated announcements obscure instructions.
- Compare visible filename, browser request, temporary upload, stored entry, notification link, retention job, and final downloadable object using a unique harmless marker.
- Repeat on Safari, Chrome, Firefox, iOS VoiceOver, Android TalkBack, Windows screen reader, 200 percent zoom, reduced motion, and a narrow viewport.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
upload_fixture:
filename: accessibility-test.pdf
sha256: record-before-upload
valid_size: 512KB
invalid_size: server-limit-plus-1
expected_states: [selected, uploading, complete, stored]
Why this usually happens
- Visual progress text changes outside an aria-live region.
- The input receives a new DOM node and keyboard focus silently returns to the page start.
- Client validation and server validation use different file limits or messages.
- A temporary object remains after a failed upload and is mistaken for the submitted file.
Decision rule
The upload is ready only when every important state is announced once, focus stays usable, errors explain recovery, and the stored entry contains exactly the file confirmed to the user.
Production verification checklist
- Selection, upload start, progress or busy state, completion, removal, replacement, and failure are perceivable without sight.
- Keyboard focus never becomes lost or trapped after a state change.
- Client and server errors identify the same rejected file and next action.
- The final entry, notification, and storage object match the confirmed filename and checksum.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Write the expected announcement sequence
- Create valid and failing file fixtures
- Test keyboard and screen reader behavior
- Reconcile temporary and stored objects
- Retest after cache and cleanup
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the public page, stored record, API response, accessibility tree, queue, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, cache, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test an accessible form.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references