Understanding WCAG SC 2.1.1 Keyboard

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. (Level A)
Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
Keyboard Transcript
Hello everyone, today we’re going to talk about keyboards. We’re also going to discuss its purpose, importance, some test keys and exceptions, failure scenarios, and how we can fix them.Plan a day without a mouse or a trackpad. Try doing your work on a computer with only a keyboard. You would notice the following: all the functions are not designed or accessible by the keyboard. Due to the lack of keyboard support, you might feel frustrated and never want to visit that site again. Maybe “frustration” is the keyword for the day.
Well, you’re not alone. Users with disabilities, older users, and even power users are with you. This is why WCAG mandates that all functionalities of the content must be accessible and operable by keyboard, except certain interactions that rely on paths.
Now, let’s see who benefits from this.
People with no vision, who cannot use a mouse due to a lack of hand-to-eye coordination.
People with limited vision, who cannot track the pointer.
People who have tremors and so cannot hold a pointing device.
Let’s look at some test keys.
Tab, which generally moves between the elements in the forward direction or left to right.
Shift + Tab, which generally moves between the elements in the reverse direction.
Arrow keys, which generally move between the values in dropdowns, sliders, etc.
Enter and Spacebar, which activate all the UI controls like buttons, links, and checkboxes.
But there are some exceptions. These include: freehand drawing, watercolor painting, flying a helicopter through an obstacle course, and adding a signature (only handwriting is an exception, not signing a document).
Now, let’s talk about some failure scenarios.
On a test page, a “match the following” question is asked, but the matching functionality is not accessible by the keyboard.
On a web page, the navigation menu with its submenus is not accessible by keyboard.
A form has an icon being used as a submit button, which is not accessible by the keyboard.
Now, let’s see how we can fix them.
One can always use native UI controls.
One can always code the controls using native markup, like for links,
This success criterion requires that all functionalities must be accessible and operable to users using a keyboard. Normally users with disabilities & elderly people depend a lot on keyboard to navigate to all parts of the web page & if any part of the web page is not operable with keyboard then it fails this check point. People generally use tab to move forward, shift+tab to move backward & screen reader users use arrow keys a lot to navigate. This success criterion addresses the needs of people with motor disabilities, visually challenged users & elderly users.