Alert - Sign-in

Examples

Required sign-in (verified)

Optional sign-in (verified)

Verify with ID.me

Verify with Login.gov

Sign in with a different account

Usage

When to use Alert - Sign-in

• Static pages with entry points to online tools. The sign-in alert appears on a static unauthenticated VA.gov page and serves as the entry point to the tool’s authenticated experience. The Office of the Chief Technology Officer’s content/information architecture/accessibility team (CAIA) team manages these pages in Drupal. Work with CAIA to add the alert to the correct page.
• Form intro pages. The sign-in alert goes on the form intro page that the product team creates and manages. The URL for this page ends in /introduction. Exception: If your form is only accessible after signing in (meaning there is no unauthenticated state of the intro page), the sign-in alert must appear on the static unauthenticated page that serves as the entry point. Currently, this only applies to 2 forms in the /my-health section: the 1010EZR and the order form for CPAP and hearing aid supplies.

Placement

• For entry points to online tools, work with CAIA to determine placement on the static page. Placement may vary depending on the page structure. Always place the alert directly under a header that makes it clear what the user is signing in to do (for example, “Check your claim status online”).
• On form intro pages, place the alert directly after the process list or “what to know” section of the intro page. (Some forms have a process list and some have “what to know.” Refer to the form into page template for that guidance.)

Behavior

Refer to the related sign-in pattern page for full guidance

All products that only allow verified accounts must implement 1 of these 2 alert variations

Required sign-in (verified)

When these are true:

• Person is not signed in, and
• Your product requires people to sign in, and
• Your product only accepts verified (LOA3 or IAL2) accounts

Optional sign-in (verified)

When these are true:

• Person is not signed in, and
• Your product is a form, and
• Your product doesn’t require sign-in, but if people choose to sign in they must use verified (LOA3 or IAL2) accounts, and
• Your form supports both prefill and save-in-progress

All products that only allow verified accounts must implement all 3 of these alerts

Verify with ID.me

When these are true:

• Person is signed in with an unverified (LOA1 or IAL1) ID.me account, and
• Your product only accepts verified (LOA3 or IAL2) accounts

Verify with Login.gov

When these are true:

• Person is signed in with an unverified (LOA1 or IAL1) Login.gov account, and
• Your product only accepts verified (LOA3 or IAL2) accounts

Sign in with another account

When these are true:

• Person is signed in with an unverified (LOA1 or IAL1) My HealtheVet account, and
• Your product only accepts verified (LOA3 or IAL2) accounts

Code usage

Attributes and Properties

Content considerations

If your product fits one of these descriptions, you may need to adjust the standard sign-in alert component content for your situation:

• A product that either requires or allows sign-in, but accepts unverified accounts
• An online form that allows sign-in but does not support prefill
• An online form that allows sign-in and offers a different reason to sign in—like generating an automatic Intent to File (ITF)
• A health tool that requires registration with My HealtheVet (currently only applies to messages, medications, and medical records tools)

Work with the CAIA and identity teams to adjust the content in this component for your product.

Accessibility considerations

• No auto-dismissal. Don’t automatically dismiss an alert based on a timer or time limit.

Assign an appropriate ARIA role

In some situations, an ARIA role may need to be added to the alert component for it to work best for people who use assistive technology. ARIA should be used sparingly to supplement and enhance the native features of HTML.

• Static alert: No Role. If the alert is a static alert that exists on the page when the page gets loaded, it doesn’t need a role.
• Important, time-sensitive information: Use role=”alert”. Use this role on alert components that appear after a user interaction. Alerts are assertive live regions, so setting role="alert" is equivalent to setting aria-live="assertive" and aria-atomic="true".

    <va-alert role="alert" ...>...</va-alert>
  

  • This is for live updates to a page that would not get noticed otherwise. Updates to a page can occur without the user refreshing the page, so these may go unnoticed when using assistive technologies. role="alert" ensures assistive technology announces these updates and keeps the user informed.
  • Because this can be intrusive to the user experience, this should be used sparingly for information that requires the user’s immediate attention.
  • Interactive alerts: Use role=”alertdialog” instead. For alerts that fit the criteria of role="alert", but also contain content requiring user interaction, use role="alertdialog" instead of role="alert". For example, expecting the user to acknowledge the alert by closing it before proceeding.

    <va-alert role="alertdialog" ...>...</va-alert>
    

• Advisory information, not important enough to have an alert role: Use role=”status”. Use this role on alert components that appear after a user interaction. This allows users with assistive tech to be notified of the change, but won’t immediately interrupt them from the current task. Elements with the role=status have an implicit aria-live=polite and an implicit aria-atomic=true.

    <va-alert role="status" ...>...</va-alert>
  

• For must-read information that is present on page load, consider using a Summary box instead of an alert.

More on ARIA: alert role, ARIA: status role.

Alternative (alt) text for icons and images

For accessibility best practices, we differentiate between images that are decorative and images that are informative.

• Decorative images: Dividers or design items that do not provide additional context or content. They may exist on the page for purely aesthetic reasons. They don’t add to the information a user needs and they make little sense, or are unnecessary, when read with a screen reader.
• Informative images: convey some kind of information. To determine whether an image is informative or not, try removing it from the design. If information is missing with the image removed it means that the image is informative and needs alt text.

Consider the purpose of your graphic and whether alt text will provide any information, benefit, or feeling (e.g. the icons used in this Alert component) If the image will not provide information, benefit, or sentiment then do not provide alt text on the image. For more information on why we must provide relevant and meaningful alt text and how to create quality alt text please refer to the content style guide on Alternative text for images.

Related

• Alert
• Pattern - Help users to sign in

Component checklist