Note 1: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Understanding 4.1.2 Show Hide techniques and failures for 4.1.2 Sufficient Advisory Failures Sufficient Techniques for Success Criterion 4.1.2 Note: Other techniques may also be sufficient if they meet the success criterion. See Understanding Techniques. Situation A: If using a standard user interface component in a markup language (e.g., HTML): ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used ARIA16: Using aria-labelledby to provide a name for user interface controls G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes H91: Using HTML form controls and links H44: Using label elements to associate text labels with form controls H64: Using the title attribute of the frame and iframe elements H65: Using the title attribute to identify form controls when the label element cannot be used H88: Using HTML according to spec Situation B: If using script or code to re-purpose a standard user interface component in a markup language: Exposing the names and roles, allowing user-settable properties to be directly set, and providing notification of changes using one of the following techniques: ARIA16: Using aria-labelledby to provide a name for user interface controls Situation C: If using a standard user interface component in a programming technology: G135: Using the accessibility API features of a technology to expose names and notification of changes PDF10: Providing labels for interactive form controls in PDF documents PDF12: Providing name, role, value information for form fields in PDF documents Situation D: If creating your own user interface component in a programming language: G10: Creating components using a technology that supports the accessibility notification of changes ARIA4: Using a WAI-ARIA role to expose the role of a user interface component ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component ARIA16: Using aria-labelledby to provide a name for user interface controls Failures for Success Criterion 4.1.2 F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link Back to top 4.1.3 Status Messages Level AA (Added in 2.1) In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.