Refine By

Login forms

  • Contents:
  • Login forms are the most common means of authenticating users.
  • They usually consists of a username/email address, a password, and a primary CTA.

Guidelines

 

  • Redact password entry as the user types, and provide a show/hide functionality
  • Clearly mark when authentication fails.
  • Show the user what went wrong and what action needs to be taken in order to successfully authenticate.
  • Provide inline validation for incorrect email entry formats.
  • Provide a link to reset credentials if the user does not remember the correct combination.
  • Allow the user to opt-in to having their credentials cookied for faster authentication on subsequent visits.
  • Properly label the login form and provide an alternate link to enrollment for new users

Available Functionality

 

Password hide and show.

Click the prototype to interact with it

Opt-in to login with fingerprint on mobile apps.

Accessibility

 

Requirements for Automated Accessibility Testing with the aXe tool:

  1. Every form field must be labeled.
  2. The Sign In button must have a name that is read to screen reader users.
  3. Minimum color contrast levels must be met.

 

Ensure that all elements are available to screen reader users (Android/Talkback; iOS/VoiceOver):

  • Swipe to ensure that you can access all static content (and welcome or other message/instructions, logo alternative text, or introductory text like “Not a Hilton Honors member?”) and to interact with CTAs (including “close window/go back” options), form elements and links.
  • Unlike desktop screen readers, all of the page content – not just interactive elements – should receive a VoiceOver/Talkback outline.
  • Make sure that all content is accessed in a logical order (e.g., when you swipe from the password field, do you move to the Remember Me checkbox?)
  • Make sure that the field labels are announced correctly (Username, Password) and that by doubletapping in the field, content can be entered.
  • Make sure that the Remember Me checkbox is announced correctly, and that the screen reader announces whether or not it is checked/selected. Double tap to select/unselect and make sure the change is announced by VoiceOver.
  • When links are announced by the screen reader, make sure that there is an announcement if they open in a new window.
  • Make sure that the Sign In button is announced as expected and can be activated with the double tap gesture.

 

 

Examples Implemented on OHW/Global Web

  • Global Web Honors sign in form (adaptive): https://secure3.hilton.com/en/hh/customer/login/index.htm
  • Implementation for sign in on OHW can be found in NHCGUEST-70

 

Known Accessibility Issues:

Sign in buttons most often are white text over the #009BE1 blue. This leads to a color contrast ratio of 3.1:1 and will most likely be shown as a failure in aXe testing. The error can be marked as a false positive as long as the font style is Bold or Xbold at 20px.

Requirements for Automated Accessibility Testing with the aXe tool:

  1. Every form field must be labeled.
  2. The Sign In button must have a name that is read to screen reader users.
  3. Minimum color contrast levels must be met.

 

Requirements for Manual Accessibility Testing:

  1. Ensure that all elements are available from the keyboard only:
  • Tabbing through the form elements and links should happen in a logical order.
  • Users should be able to tab to all form elements (Username and Password fields, Remember Me checkbox, etc.)
  • When hover states are used, the same effect should be shown when the element receives keyboard focus.
  • When each element receives keyboard focus, it should have a visible focus indicator (visible focus varies by browser).
  • It should be possible to select elements from the keyboard only:
    • Checkboxes should be able to be selected with the spacebar
    • Buttons should be able to be activated with the spacebar or enter key
    • Links should be able to be opened using the enter key

 

Ensure that all elements are available to screen reader users (with JAWS/IE, NVDA/Firefox, or VoiceOver/Safari):

  1. Use the up/down arrows to access static content (and welcome or other message/instructions, logo alternative text, or introductory text like “Not a Hilton Honors member?”)
  2. Use the tab key to interact with form elements and links.
  3. Make sure that the field labels are announced correctly (Username, Password).
  4. Make sure that the Remember Me checkbox is announced correctly, and that the screen reader announces whether or not it is checked/selected.
  5. When links are announced by the screen reader, make sure that there is an announcement if they open in a new window.
  6. Make sure that the Sign In button is announced as expected.

 

 

Examples Implemented on OHW/Global Web

  1. Global Web Honors sign in form: https://secure3.hilton.com/en/hh/customer/login/index.htm
  2. Implementation for sign in on OHW can be found in NHCGUEST-70

 

Known Accessibility Issues:

Sign in buttons most often are white text over the #009BE1 blue. This leads to a color contrast ratio of 3.1:1 and will most likely be shown as a failure in aXe testing. The error can be marked as a false positive as long as the font style is Bold or Xbold at 20px.

Related Elements

Version History

Date/Time of ChangeWho Made the ChangeChange Details
May. 08 2017 5:57pm Initial content entry