Check a Landing Page With Only Your Keyboard Before Sharing It

Many people rely on keyboard input or assistive technology that uses keyboard commands. W3C’s accessibility guidance calls for keyboard access to functionality, including forms and controls. This matters whether your page began with a template, an AI-generated layout or custom code. W3C accessibility principles

Start with one realistic journey

Choose a task such as opening the services menu, finding a package and reaching the enquiry form. Work on a preview or staging copy so that testing cannot accidentally send a real enquiry or complete a purchase.

Put the mouse aside. Use Tab to move forward and Shift+Tab to move backward. Check your browser and operating-system keyboard-navigation settings if some controls appear to be skipped. Different controls use different keys: links commonly use Enter, while select lists may require arrow keys. W3C’s preliminary keyboard checks

Write down the browser, page address and task before you begin. This makes a later bug report easier to reproduce.

Watch where focus goes

Keyboard focus identifies the element that will receive your next action. As you move, you should be able to tell which link, button or field is active. A border, outline or other clear visual treatment can provide that cue.

Pause on the main call-to-action. Can you identify it without guessing? Check the same thing against light sections, dark sections and image backgrounds. A focus indicator should remain visible while the element has focus; a brief animation that disappears is insufficient. W3C: Focus Visible

Also check that sticky headers, cookie banners or other overlays do not entirely hide the focused control. W3C: Focus Not Obscured

Next, watch the sequence. Does it follow a meaningful route, or jump unpredictably between unrelated areas? The order does not have to copy every visual position exactly, but it must preserve meaning and operation. A contact form that alternates between unrelated groups of fields deserves investigation. W3C: Focus Order

Open things, then close them

Test expandable menus, FAQ controls and dialogs as part of the journey. Reaching a control is only the beginning; try its actual function and return to the page.

For a modal dialog, focus normally moves inside when it opens. Tab and Shift+Tab cycle through its controls, Escape closes it, and focus usually returns to the control that opened it. Check that a visible close or cancel button is available too. W3C’s modal dialog pattern

Keeping focus inside an open modal can be intentional. Being unable to leave or close a component using the keyboard is the problem. If an unusual exit method is necessary, users need to be told how it works. W3C: No Keyboard Trap

Turn observations into fixes

Record one issue per note: the starting point, keys pressed, expected result and actual result. “Tab reaches the enquiry button, but no visible focus appears” is more useful than “accessibility feels broken.”

After a fix, repeat the same journey and check neighboring controls. Keep the result modest: this is an initial keyboard review. It does not establish full accessibility or WCAG conformance. W3C explicitly warns that pages passing its easy checks can still contain significant barriers. Use the findings to guide a broader assessment. W3C’s review scope

Documentation-based workflow; no hands-on test of a specific website is claimed.