Phone Input

Use a phone input to add an international phone number.

Examples

Key	Function
`Tab`	Moves focus to the next focusable element.
`Shift + Tab`	Moves focus to the previous focusable element.
`Enter`,`Space`	Submits the entered value.

For comprehensive details on keyboard support, refer to our Keyboard Control Guide.

Visit WebAIM for keyboard techniques.

Ensure simplicity since not all browsers handle multiple labels linked to the same form element correctly.
Label Usage: Assign a label to each input field and make sure the for="" attribute of the label matches the id="" of the corresponding input. Remember, each id must be unique on the page, and each form element should have only one associated label.
Indicating Required Fields: Clearly mark required fields using indicators like an asterisk (*) or descriptive text to make them easily identifiable.
Help Text: Incorporate help text for all form fields, especially those with constraints. This text should be programmatically associated with the input, for example, using aria-describedby. This is particularly important for masked fields.
Test compatibility with various screen readers (like JAWS, NVDA, or VoiceOver) to ensure the phone input component is announced correctly. Options should be clearly read out when navigated.
Error Validation: Fields with validation errors should use aria-describedby to ensure that error messages are accessible to assistive technologies. If an error message has an id="my-error-message", the corresponding input should include aria-describedby="my-error-message"

Design with simplicity to accommodate all browsers, minimizing complexities that could hinder accessibility.
Obvious Required Fields: Use visual cues, such as an asterisk (*) or supplementary text, to clearly mark required fields and make them easily distinguishable.
User-Friendly Help Text: Place help text or examples directly below or inside the phone input field to guide users on the correct format.
Visible Error Feedback: Design error messages to appear clearly near the phone input field when validation fails, using color, icons, or text to make them noticeable.
Sufficient Tap Targets: Ensure phone input fields have large enough tap targets to accommodate users with different levels of dexterity, following touch-friendly design principles.
Use spacing, typography, and visual cues effectively.
Maintain consistency in the design of the phone input to provide a cohesive user experience.

Find live examples of accessible inputs with different types in DigitalA11y project.

Mozilla Resources for Developers: Information about the HTML input-type="tel"
A11y style guide: Describes core principles for the accessible inputs and textarea.
MagentaA11y: How to test a number input.

Explore additional accessibility tips in the general Accessibility Guide.

Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. (Level A)
Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
Headings and Labels: Headings and labels describe topic or purpose. (Level AA)
Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)
Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)