Section508.gov

Accessibility testing for dynamic forms, including HTML-based forms and software forms, typically require a different approach than testing static content. Because these forms generate and alter content in response to user input, the form presents accessibility data to assistive technology (AT) differently as content changes. Rather than viewing them simply as static files, testers should treat dynamic forms as interactive experiences. Below are practical strategies for assessing these forms for Section 508 compliance.

Dynamic forms may:

Add, remove, or reveal content during user interaction.
Expand or collapse sections based on user selections.
Generate pages dynamically.
Recalculate values automatically.
Present different content paths depending on user responses.

These behaviors can introduce accessibility barriers if the form does not provide sufficient information to users about changes or does not support effective navigation.

The most common challenges with dynamic forms include:

Missing or Limited Programmatic Information: Many accessibility testing techniques rely on inspecting underlying code, document structure, and programmatically exposed accessibility information to determine heading structure, reading order, form field associations, table markup, sufficient alternative text, and programmatic lists. Dynamic forms may not expose this information through web, software or PDF tag inspection tools. Testers may need to use additional tools or testing methods.
Content Changes Based on User Interaction: Content may appear only after checking a checkbox, choosing a radio button, selecting an option from a list, or entering data. Test these changes to confirm that AT users receive equivalent information.
Variability in User Experience: Dynamic forms behave differently across Adobe Acrobat Reader, browsers, browser-based viewers, applications, and AT.

Testing for Section 508 Conformance

Apply the applicable Section 508 standards. For web content and electronic documents, this includes Web Content Accessibility Guidelines (WCAG) 2.0 Level A and Level AA Success Criteria, which the Section 508 Standards incorporate by reference. For software-based forms, also consider applicable Chapter 5 requirements. For support materials or instructions, consider applicable Chapter 6 requirements. Use the appropriate ICT Testing Baseline.

Test the form in the environment the agency expects or instructs users to use. If the agency requires users to open the form in a specific application, test in that application. If users can access the form in multiple supported environments, test each supported environment and document the tested environment. Before testing, identify how users access and complete the form.

The testing approach may differ depending on whether the form is:

A web-based form rendered in a browser.
A PDF form opened in Adobe Acrobat.
A dynamic XFA/PDF form.
A form embedded in a web application.
A form generated by software or a document service.
A form that produces a completed PDF, receipt, or confirmation page.

Depending on the type of form, you may need to use:

A screen reader
Microsoft’s Accessibility Insights
The Accessible Name and Description Inspector (ANDI)
Browser Developer Tools.
The content authoring tool.

Table 1. Testing Tools for Dynamic Forms
Form Delivery Type	Testing Tools or Methods
Web-based form	Browser, keyboard, Accessibility Insights, ANDI, browser accessibility tree or inspector, screen reader
PDF-based form	Adobe Acrobat Reader, Adobe Accessibility Checker, PDF accessibility tools, keyboard, screen reader
Dynamic/XFA PDF form	Supported PDF viewer, keyboard, screen reader, Adobe Acrobat/Designer tools where applicable
Form embedded in an application	Supported application environment, keyboard, screen reader, accessibility inspection tools supported by the platform

Automated testing tools can help identify missing labels, incorrect roles, missing document structure, or values the form exposes to AT. However, these tools do not confirm whether a user can successfully complete the form. Testers must use manual testing to evaluate focus behavior, dynamic updates, error recovery, and the overall user experience.

Testing Scope

Dynamic forms typically have multiple possible paths. When testing every possible combination is not practical, identify and document the paths you tested. At minimum, test:

The default path through the form.
Any required path and associated form field validation.
Each type of conditional branch.
Each type of dynamic interaction.
Each error type.
Each type of calculation or auto-populated field.
The submission workflow.
Any high-risk path involving legal, financial, personal, medical, benefits, eligibility, or official data.

For multi-page or paginated forms, also verify:

The form communicates the current step and total number of steps to AT.
Navigating to a previous page preserves the user's entered data.
Focus moves to a logical starting point when a new page or section loads.
The page or section title updates to reflect the current step.

Testing Dynamic Content

After determining test coverage, evaluate the form components and behaviors that appear within the selected paths. Dynamic behavior can affect keyboard access, focus order, accessible names and descriptions, error handling, field relationships, and the information the form exposes to AT.

For each dynamic interaction, verify that users can understand and operate the form with a keyboard and AT. Check that each form control exposes:

A meaningful accessible name or description.
Input formats.
The correct role, such as text box, checkbox, radio button, or button.
The correct state, such as checked, selected, expanded, collapsed, disabled, or invalid.
Required field status.
The current value.
Related instructions, help text, and error messages.
Dynamic content changes.

Also check that:

Content is presented in a logical sequence.
Keyboard users and AT can reach and access new content.
The form removes hidden content from keyboard navigation.
A user can successfully complete and submit the form using a keyboard and AT.

Recommended Test Procedure

Before you begin: Disable browser extensions that may interfere with accessibility testing. Set your screen reader to its default verbosity. For XFA or dynamic PDF forms, confirm that Adobe Acrobat is set to open the form in the correct rendering mode. Clear session data between test runs to ensure dynamic content behaves consistently.

Open the form in the supported environment. Document the environment, test method, and testing tools you use.
Review the initial form structure, including title, instructions, headings, labels, and starting point.
Navigate the form using only the keyboard.
Verify that all controls are reachable, operable, and have visible focus.
Confirm that focus moves in a logical order.
Trigger each dynamic interaction, including conditional questions, expandable and collapsable sections, repeating sections, calculations, and validation.
Verify that keyboard users can reach newly displayed content and that the form removes hidden content from keyboard navigation.
Test each form field with assistive technology such as a screen reader, for name, role, state, value, required status, instructions, and errors.
Trigger validation errors and verify that users can identify, locate, understand, and correct each error. Use a screen reader to validate AT provides error notification.
Complete and submit the form using only a keyboard and a screen reader.
Verify that the form presents accessible confirmation messages, receipts, completed forms, and any documents it generates.
Record each issue with steps to reproduce, what Section 508 standard fails, location, expected result, actual result, and severity. See also Essential Elements of an Accessibility Test Report.

Dynamic forms introduce accessibility barriers that automated tools and standard tag inspection do not always catch. The defects in Table 2 reflect issues commonly found during manual testing of dynamic forms. Each entry identifies the component, an example defect, the impact on users, the relevant WCAG success criteria, and a test instruction for evaluating the issue. Use this table as a reference when evaluating dynamic form components and documenting test findings.

Table 2: Common Dynamic Form Defects

Component	Example Defect	User Impact	Associated WCAG Criterion	Test Instruction
Tables	Dynamic table lacks row/column associations.	Screen reader users cannot understand data relationships.	1.3.1 Info and Relationships	Check that each data cell is programmatically associated with its header(s).
Form Field Name	The screen reader does not announce an accessible name for the text field.	Screen reader users cannot determine the purpose of the form field.	1.3.1 Info and Relationships 4.1.2 Name, Role, Value	Verify the screen reader announces all meaningful labels.
Required Fields	The form conveys required status only visually, such as with a red asterisk.	Screen reader users may not know the field is required.	1.3.1 Info and Relationships 3.3.2 Labels or Instructions	Verify required status is programmatically exposed.
Instructions	Instructions appear visually but the form does not associate them with form fields.	Screen reader users may miss critical completion guidance.	1.3.1 Info and Relationships 3.3.2 Labels or Instructions	Confirm users encounter instructions before they begin data entry, or verify the screen reader programmatically exposes instructions for the associated form field.
Radio Buttons	The screen reader does not announce the group purpose.	Users cannot understand available choices.	1.3.1 Info and Relationships 4.1.2 Name, Role, Value	Test group labeling to ensure programmatic association.
Checkboxes	Checkbox purpose unclear.	Users cannot make informed selections.	1.3.1 Info and Relationships 4.1.2 Name, Role, Value	Verify programmatic label association.
Confirmation or Receipt	The form displays submission confirmation visually only, or the system generates inaccessible output.	Users may not know whether they submitted the form successfully or may not be able to use the receipt.	1.3.1 Info and Relationships 4.1.2 Name, Role, Value 3.3.1 where applicable	Submit the form and verify the confirmation, receipt, or generated is accessible.
File Upload	File upload control has unclear instructions or inaccessible error messages.	Users may not know how to attach required documents or correct upload errors.	1.3.1 Info and Relationships 3.3.1 Error Identification 3.3.2 Labels or Instructions 4.1.2 Name, Role, Value	Test file selection, upload, upload errors, and file removal using keyboard and AT.
Reading Order	Screen reader reads content out of sequence.	Users cannot understand workflow.	1.3.2 Meaningful Sequence	Using AT, navigate the form sequentially and confirm that AT reads all meaningful content in a logical sequence.
Color-Only Indicators	The form conveys status or instructions only through color.	Users with color vision deficiencies miss information.	1.3.3 Sensory Characteristics 1.4.1 Use of Color	Check that color alone is not the only method to indicate status or provide instructions.
Text Contrast and Resizing	Text has insufficient contrast or resizing causes content to disappear.	Users with low vision may not be able to read or complete the form.	1.4.3 Contrast Minimum 1.4.4 Resize Text	Check text contrast and resize text up to 200 percent without loss of content or functionality.
Keyboard Navigation	Keyboard users cannot reach a form field or button.	Keyboard-only users cannot complete the form.	2.1.1 Keyboard	Test the entire dynamic form using only a keyboard.
Date Pickers	Calendar control inaccessible via keyboard.	Users cannot enter a date.	2.1.1 Keyboard 4.1.2 Name, Role, Value	Check that an alternative method to input the date is available, such as manual numerical entry.
Modal Dialogs or Help Pop-ups	A help dialog opens but focus does not move to it, or users cannot close it with the keyboard.	Keyboard and screen reader users may become disoriented or trapped.	2.1.1 Keyboard 2.1.2 No Keyboard Trap 2.4.3 Focus Order 4.1.2 Name, Role, Value	Open each dialog. Verify focus management, accessible name, keyboard operation, and logical focus return.
Keyboard Trap	The user enters a control but cannot leave it using the keyboard. This can be a common issue with custom widgets.	The user becomes stuck.	2.1.2 No Keyboard Trap	Ensure focus can be moved away from each interactive interface component.
Session Timeout	The form does not announce the timeout warning, or users cannot extend the session using the keyboard.	Users may lose data or be unable to complete the form.	2.2.1 Timing Adjustable	Verify users receive an accessible timeout warning and can extend the session when allowed.
Focus Order	Tab order does not follow visual or logical sequence.	Navigation is confusing.	2.4.3 Focus Order	Using the keyboard, tab through the form. Check that the focus order preserves the meaning and usability of the content.
Hidden Dynamic Content	The form keeps hidden content in the keyboard tab order.	Keyboard users encounter irrelevant controls.	2.4.3 Focus Order	Using the keyboard, tab through the form. Hidden content should not remain in tab order.
Focus After Dynamic Updates	Focus unexpectedly jumps after selection.	The keyboard user loses context.	2.4.3 Focus Order 3.2.1 On Focus	Using the keyboard, trigger dynamic content and check that the focus order preserves the meaning and usability of the content, including predictable behavior.
Visible Focus	The form does not display a visible keyboard focus indicator.	Keyboard users cannot identify their current location.	2.4.7 Focus Visible	Using the keyboard, tab through the form, triggering dynamic content. Verify there is always a visible indication of focus.
Language	The form or part of the form uses another language without programmatic identification.	Screen readers may pronounce content incorrectly.	3.1.1 Language of Page 3.1.2 Language of Parts	Verify the form language and any language changes are programmatically identified.
Change on Input	Selecting an option automatically moves the user to another page or section without warning.	Users may lose context or be unable to predict what will happen.	3.2.2 On Input	Change each control value and confirm the form does not cause an unexpected change of context unless users are warned before the interaction.
Error Identification	The form displays validation errors visually only.	Screen reader users may not know submission failed.	3.3.1 Error Identification	Trigger all validation rules, including attempting to submit with incomplete form fields or incorrect data.
Error Location	Users cannot easily locate fields with errors.	Increased completion difficulty.	3.3.1 Error Identification 3.3.3 Error Suggestion	Trigger the error and verify the user is made aware of the error, the error is described to the user in text, and the item in error is identified in text.
Error Suggestions	The error message identifies a problem but not a solution.	Users may not know how to correct issues.	3.3.3 Error Suggestion	Check that there are suggestions or guidance for how the user can correct the error.
Error Prevention	The form submits legal, financial, or personal data without allowing users to review, correct, or confirm entries.	Users may submit incorrect information with serious consequences.	3.3.4 Error Prevention Legal, Financial, Data	For forms that submit legal, financial, or user-controlled data, verify users can review, correct, or confirm information before final submission.
Expand or Collapse Sections	Expand/collapse state not announced.	Users cannot determine current state.	4.1.2 Name, Role, Value	Verify that AT announces the expanded or collapsed state of each section.
Dynamic Content Reveal	Additional questions appear but the screen reader does not announce them.	Screen reader users may not know new content exists.	4.1.2 Name, Role, Value	Using AT, test all conditional logic paths to verify newly revealed content is programmatically exposed.

Use this checklist when testing dynamic forms to verify Section 508 conformance. This applies to forms delivered as webpages, PDFs, or applications.

Supported Test Environment

The tester performed testing in the agency-supported environment.
The tester documented the browser, PDF viewer, operating system, screen reader, and versions used.
If the agency supports multiple environments, the tester tested each one or documented the test methods.

Form Structure and Navigation

All form fields, buttons, and controls are reachable using only a keyboard.
The keyboard does not get trapped in a section of the form.
Focus indicators are visible throughout the form.
Focus moves in a logical order that supports completing the form.
Related controls are grouped together logically.
Keyboard users cannot reach hidden content.
New content appears in a predictable location when the user triggers it.
Keyboard users can access newly displayed content.
Dynamic updates do not cause unexpected focus changes.
The form informs users when content changes as a result of their interaction.
The form exposes updates such as calculations, confirmations, or conditional content to AT.
For multi-page or paginated forms, verify that the form communicates the current step and total steps to AT, moves focus to a logical starting point when each page loads, updates the page or section title to reflect the current step, and preserves entered data when the user navigates to a previous page.

Form Field Identification (Name, Role, State, and Value)

Each form field has a visible label to describe its purpose and required formatting.
Each field has a meaningful accessible name that includes purpose, required, and formatting.
Role is correctly identified (e.g., textbox, checkbox, button).
Current value is announced or exposed correctly.
The form programmatically conveys required fields.
Each form field correctly identifies its state such as checked or selected.

Error Handling

The form identifies errors in text, not just visually.
The form programmatically associates errors with the correct field.
The form notifies screen reader users of errors.
Error messages provide clear guidance for correction.
Users can easily locate and correct errors.
For legal, financial, or data submissions, users can review, correct, or confirm information before final submission.
The system generates accessible receipts, confirmation pages, and completed PDFs.

Dynamic Form Coverage

Test different paths a user can take, such as:

Conditional questions (Yes/No branches).
Expandable sections.
Repeating or add/remove sections.
Calculated or auto-populated fields.
All validation error scenarios.
Complete submission workflow.

Session and Data Loss

The form presents accessible timeout warnings.
Verify that for each time limit the content sets, the form lets the user turn it off, adjust it to at least ten times the default, or receive a warning before it expires and extend it at least ten times using a simple keyboard action.
Users do not lose entered data unexpectedly.

Visual Accessibility

Text and meaningful visual information meet contrast requirements.
Text can be resized up to 200% without loss of content or functionality.
The form does not provide instructions and labels only as images of text.
Instructions the form provides for understanding and operating content do not rely solely on sensory characteristics such as shape, size, visual location, orientation, or sound.

Other Common Dynamic Components

Keyboard users can access help text, tooltips, and modal dialogs.
Date pickers provide an accessible manual entry option.
Keyboard and AT users can access file upload controls and upload error messages.
Keyboard and AT users can access electronic signature controls, if present.
CAPTCHA or verification steps provide accessible alternatives, if present.

Related Resources:

*Disclaimer: Reference in this site to any specific commercial product, process, or service, or the use of any trade, firm or corporation name is for the information and convenience of the public, and does not constitute endorsement, recommendation, or favoring by GSA. GSA does not guarantee that outside websites or products comply with Section 508 (accessibility requirements) of the Rehabilitation Act.

Reviewed/Updated: November 2026

Testing Dynamic Forms