G202: Ensuring keyboard control for all functionality Ensuring keyboard control by using one of the following techniques. H91: Using HTML form controls and links PDF3: Ensuring correct tab and reading order in PDF documents PDF11: Providing links and link text using the Link annotation and the /Link structure element in PDF documents PDF23: Providing interactive form controls in PDF documents G90: Providing keyboard-triggered event handlers SCR20: Using both keyboard and other device-specific functions SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons SCR2: Using redundant keyboard and mouse event handlers Advisory Techniques for Success Criterion 2.1.1 SCR29: Adding keyboard-accessible actions to static HTML elements Failures for Success Criterion 2.1.1 F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links Back to top 2.1.2 No Keyboard Trap Level A If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. Note 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference. Understanding 2.1.2 Show Hide techniques and failures for 2.1.2 Sufficient Advisory Failures Sufficient Techniques for Success Criterion 2.1.2 Note: Other techniques may also be sufficient if they meet the success criterion.