Accessibility of a site: first tests by keyboard and on mobile

Web accessibility and performance · 6 min reading

To carry out initial accessibility tests of your site on the keyboard and on mobile, try a useful route without a mouse, then on a real phone. Verify that each command remains accessible, identifiable and usable, even with enlarged text. Document blockages with steps to reproduce them. This approach prepares targeted corrections; it does not allow the site to be declared compliant.

Key points

• Test a complete action, not just the appearance of the welcome.
• A visible button is not necessarily usable on the keyboard.
• On mobile, also control forms, zoom and fixed elements.
• After correction, replay exactly the same route.

Prepare tests without disrupting activity

Choose a common path: find a service and complete a request, or select a product and join the basket. Add shared components, such as the menu, search and consent banner. Note the address of each page, the browser and the device used.

For form submissions or payments, use an authorized test environment. On the public site, stop before an action that would create a real request or order. Prepare an anomaly list with four pieces of information: steps, observed result, expected result and visual evidence.

Test keyboard navigation

Follow focus from command to command

Go to the address bar, then use Tab to move forward and Shift + Tab to move back. The focus designates the element that receives keyboard commands; a visual cue must make it possible to locate it. It must remain visible and follow an understandable order, according to the first checks of W3C. If you lose this marker, note the last identifiable command.

Try Enter on links and Enter or Space on buttons, depending on how they work. For components that provide this, also use the arrows. Check that the same actions remain available without mouse hovering: open the menu, choose a variant, remove an item from the cart.

Check openings and exits

Open each panel or window overlay on the keyboard. Can you reach its contents and closure? After closing, can you resume navigation at a consistent location? Focus contained in an open window is not necessarily a problem. The blockage appears if you can no longer exit it using an accessible command, without resuming the mouse.

Control the site on a phone

Redo the route in portrait, then look at what changes in landscape. Try the orders close to each other: filter, quantity, closure, delivery choice. Note the supports that trigger a bad action. Check that a fixed banner does not hide useful content or the button to continue.

Enlarge text with available settings. On a computer, complete with a 200 % zoom test and, if possible, by enlarging the text alone. The labels and messages must remain legible, without overlapping. The redistribution criterion of W3C provides, for vertically scrolling content, a width equivalent to 320 pixels CSS without scrolling in two directions, with exceptions for parts that actually require a two-dimensional layout, such as certain maps or data tables. These exceptions do not automatically extend to the rest of the page. A telephone test alone does not verify this criterion.

Check forms while typing

Do the fields retain an understandable title once completed? The guide W3C on labels recommends labels associated with fields. Do not mistake an indication that disappears during typing for sufficient wording. In a test environment, leave a required field empty: identify the error, find the field and correct it. On the phone, also check what the virtual keyboard hides.

Illustrative example: a menu impossible to exit

In this fictional example, a ceramics store displays an overlaid mobile menu. Its opening works with the keyboard, but its closing cross is not accessible. The anomaly is described as follows: open the menu with Enter, browse its links with Tab, note the absence of an accessible closure. The expected result is to be able to close the menu on the keyboard, then resume navigation.

The correction must restore the operation of keyboard closing and a consistent return of focus; enlarging the cross is not enough. The following test checks these two points, then checks the touch closure. No commercial results are inferred from this example.

Operational checklist

• Define the journey and its final actions, with a secure testing framework.
• Go to each command on the keyboard and locate the focus.
• Open and close menus, panels and windows without a mouse.
• Test choices, input and errors on the phone.
• Check the magnification and fixed elements.
• Transmit each anomaly with its steps and expected result.
• Replay the affected courses after correction.

Limitations and common errors

An automatic tool or mobile capture does not replace these tests. Testing only the reception leaves out the decisive steps. Confusing visual comfort and complete accessibility is also risky: these tests do not cover all contrasts, image alternatives, multimedia content or uses with assistive technologies. W3C specifies that its preliminary checks may miss significant obstacles.

Frequently asked questions

Why test without a mouse if visitors use it?

Some visitors navigate by keyboard or use devices that rely on keyboard commands. The test reveals inaccessible commands and dead ends that the mouse can hide.

Is the mobile computer display enough?

It helps to examine the layout, but does not reproduce everything: touch, virtual keyboard, phone settings and browser behavior. Complete it on a real device.

Do these controls prove regulatory compliance?

No. They identify some of the obstacles. Conformity assessment requires an appropriate scope and method; Obligations applicable to your business require separate verification.

Next step

Document the first block preventing an important action, then assign its correction with an observable validation criterion. To locate this support in your project, consult the services 4SYSTEM. Keep your test sheet to verify the correction.

Sources and resources

• W3C: first accessibility checks.
• W3C: understand content redistribution.
• W3C: associate labels with fields.