Help users to…

Complete screening questions

Also known as: Check eligibility

Usage

When to use this pattern

• When data supports the need to screen users before completing a form. If analytics or research shows a high rate of declined applications due to specific criteria, screening questions at the beginning of a form can help users understand whether they should continue. Show users a summary of their screening results to help them decide whether to continue.
• When you need to ask questions that help guide users but can’t definitively determine eligibility. Use this pattern to provide feedback based on screening responses, but avoid language that claims to confirm or deny eligibility. We can’t guarantee 100% accuracy in screening questions.

Design principles

• Showing users feedback based on their screening responses gives them the option to exit what may be a lengthy application process if they’re unlikely to qualify. This feedback also gives users a way to review and correct their answers early in the process.
• This pattern is an example of introducing useful friction in the process by anticipating possible errors that would cause us to decline an application.
• Screening questions should appear after the Introduction page, which already provides eligibility information as a first gate.

When not to use this pattern

• When you can convey information through content alone. Before adding screening questions, first consider whether you can describe eligibility criteria, form purpose, and instructions in the static content on the Introduction page. This eliminates the need to add pages and time to the form flow.
• When building unnecessary friction. Don’t wrap 2-3 simple questions in a full sub-task flow when we can include the questions in the main form or as introductory content.
• To claim definitive eligibility determination. This pattern shows screening results, not final eligibility decisions. Avoid language that could indicate someone definitely is or isn’t eligible for a benefit based on screening questions.
• When eligibility is short and concise. If you have 3 or fewer eligibility requirements, present them on the form’s introduction page as a bulleted list instead of creating a separate screening flow. This makes the content searchable and reduces unnecessary friction.
• When complex requirements need screening. If eligibility involves multiple branching paths and dependencies, use a full screening flow with a summary page that includes alerts showing whether users may continue. Only use this approach as a last resort and justify it with user research and data.

Examples

CHAMPVA screening question

This example shows a screening question with help text:

<h2>Eligibility for TRICARE</h2>

    <!-- Question heading -->
    <va-radio
      label="Is the Veteran or any of the applicants eligible or enrolled in TRICARE (the Defense Department's health care program for service members and their families)?"
      name="tricare-eligible" required>
      <va-radio-option label="Yes" value="yes"></va-radio-option>
      <va-radio-option label="No" value="no"></va-radio-option>
    </va-radio>
    
    <div class="vads-u-margin-top--3 vads-u-margin-bottom--2">
      <!-- Help text -->
      <va-details label="How to check for TRICARE eligibility" id="tricare-eligibility" width="2xl">
        <p>
          The Veteran's uniformed service decides who is eligible for TRICARE and it gets reported in the Defense Enrollment Eligibility Reporting System (DEERS).
        </p>
        <va-link href="javascript:void(0)" text="Check if the Veteran is eligible on the TRICARE website" external="true"></va-link>
      </va-details>
    </div>
  

Content structure examples

Introduction page with eligibility requirements

• Present eligibility requirements as a bulleted list using plain language
• Link to detailed information where needed
• Allow users to self-assess before starting the application

Summary card with eligibility status

• Include plain-language explanations of complex eligibility requirements
• Provide accessibility-compliant visual and text indicators
• Include a descriptive heading based on responses: “[You/The applicant] may be eligible for [program/benefit]” or “[You/The applicant] [don’t/doesn’t] meet all eligibility requirements”
• Include an introduction before the eligibility requirement list that says “Based on your answers so far, here’s how we checked eligibility:”

Alert variants for screening summary pages

When using a full screening flow, show an alert at the top of the summary page to communicate the screening result:

• Likely eligible: Green success Alert encouraging users to continue
• May not meet eligibility requirements: Yellow warning Alert explaining that the user doesn’t meet all the requirements with the option to continue or exit

Eligibility summary with VADS components

This example shows how to build an eligibility summary:

<div class="site-component-example vads-u-padding--3 vads-u-background-color--white">

    <!-- Alert based on screening results -->
    <va-alert status="warning" class="vads-u-margin-top--3">
      <h2 slot="headline">You may not meet all eligibility requirements</h2>
      <p class="vads-u-margin-y--0">Based on your answers, you may not meet all the requirements for CHAMPVA benefits. You can exit this application or continue to complete it.</p>
    </va-alert>

    <h3 class="vads-u-margin-top--3">Based on the Veteran’s information, the applicant(s) may not be eligible</h3>
    
    <!-- Introduction before eligibility list -->
    <p class="vads-u-margin-top--3 vads-u-margin-bottom--2">
      Here's how we checked eligibility:
    </p>
    
    <!-- Requirements met card -->
    <va-card class="vads-u-margin-bottom--2">
      <div class="vads-u-margin-bottom--2">
        <va-tag-status status="success" text="Requirements met"></va-tag-status>
      </div>
      
      <p class="vads-u-margin--0">
          <strong>Yes</strong>, the Veteran is permanently and totally disabled from a service-connected 
          disability, <strong>or</strong> the Veteran died from a service-connected disability, 
          <strong>or</strong> the Veteran, at the time of their death, was rated permanently 
          and totally disabled from a service-connected disability.
      </p>
    </va-card>
    
    <!-- Requirements not met card -->
    <va-card class="vads-u-margin-bottom--2">
      <div class="vads-u-margin-bottom--2">
        <va-tag-status status="error" text="Requirements not met"></va-tag-status>
      </div>
      
      <p class="vads-u-margin--0">
        <strong>No</strong>, the Veteran or applicant is eligible for TRICARE.
      </p>
    </va-card>

    <va-details label="What to do if the applicants don't meet the eligibility requirements" id="eligibility-requirements-not-met">
      <p>
        The applicants must meet all the eligibility requirements so far to be eligible for CHAMPVA benefits.</p>
      <p>If you think the eligibility summary is wrong, select <strong>Back</strong> to check your answers.</p>
      <p>If you think they're still eligible, you can continue with your application.</p>
    </va-details>
    
    <!-- Exit guidance -->
    <p class="vads-u-margin-top--3">
      If you didn't meet all the eligibility requirements for CHAMPVA benefits, you can 
      exit this application.
    </p>
    
    <!-- Exit application action link -->
    <p class="vads-u-margin-top--2">
      <va-link-action 
        href="#" 
        text="Exit application"
        type="secondary">
      </va-link-action>
    </p>
    
    <!-- Continue guidance -->
    <p class="vads-u-margin-top--3">
      If you met all the eligibility requirements or think the applicants may still be eligible, select <strong>Continue</strong> to complete your application.
    </p>
    
</div>

How to design and build

How this pattern works

• Alert the user if they don’t meet the eligibility requirements and provide options. Let users know if they haven’t met all requirements based on their answers. Provide options to exit, finish later, or continue with the application.
• Provide a clear summary of eligibility requirements met and not met. This allows users to adjust their answers if they believe the determination is incorrect. You don’t need to repeat this message throughout the application for users who choose to continue.
• Structure requirements as separate list items. Each eligibility requirement should be a separate list item so assistive technology can read each item independently.
• Use plain language and avoid claiming definitive eligibility. Don’t say someone is definitely eligible or not eligible—that decision isn’t final until after we review the application.

Reuse screening data in the main form

When using a full screening flow with screening questions, pre-fill main form fields with screening answers. Use the know when their information is prefilled pattern to alert users about pre-filled information they can review and edit.

Benefits: Reduces user burden, saves time, and improves data accuracy by preventing users from answering the same questions twice.

Content considerations

• Use plain language. Use short sentences and familiar terms that Veterans can easily understand. Follow the readability and plain language guidance in the style guide.
• Include clear “Yes” and “No” labels. Don’t rely on icons (like a check mark or X) alone to communicate eligibility status.
• Include context for complex requirements. When eligibility requirements are nuanced, provide plain-language explanations alongside the yes/no determination.

Eligibility requirements list

List each requirement with clear “Yes” or “No” labels:

• If the user met the eligibility requirement, use “Yes, [plain language description of the requirement].”
• If the user didn’t meet the eligibility requirement, use “No, [plain language description of how the person doesn’t meet the requirement].”

Accessibility considerations

Required accessibility features

• Use programmatic text labels for all eligibility outcomes. Each requirement must have a text label (“Yes” or “No”) that screen readers can access. Don’t use icons alone to indicate status.
• Structure as discrete list items. Present each eligibility requirement as a separate list item (<li>) so assistive technology reads each outcome independently rather than as a continuous paragraph.
• Ensure adequate color contrast. Status indicators must meet WCAG color contrast requirements and not rely solely on color to convey meaning.
• Support keyboard navigation. All interactive elements (exit and continue links) must be accessible using a keyboard.

Examples

Related

• Complete a sub-task: Alternative approach for complex eligibility with multiple branching paths
• Form introduction template: Where to present simple eligibility requirements
• Experimental design process: How to validate pattern variants
• Alert component: Used to communicate eligibility status
• Tag - Status component: Used to showing elgibility requirements met
• Card component: Used to show eligibility markers