Shane Ian Murphy: UK product design needs a keyboard route through the whole task

A product demonstration often follows the path its presenter knows best. A pointer moves smoothly between controls, a menu opens and the next screen appears. That sequence can show what an interface looks like without showing whether someone can complete the same task using a keyboard.

This company-origin editorial features Shane Ian Murphy and considers a practical design question for UK readers following Global Secure. The company's stated launch plan is 2027. The example is a proposed review exercise, not a report of a completed accessibility assessment. AI assistance was used in preparing this article.

Choose a task with an ending

A keyboard review becomes more useful when it follows an ordinary task rather than an arbitrary collection of buttons. Imagine a prototype in which a person changes a notification preference and returns to the account summary. The reviewer needs to move through the whole sequence, including any help panel or confirmation step.

The question is not simply whether the first control can be selected. It is whether the person can understand where they are, reach the necessary controls and finish the intended action. A successful first interaction should not conceal a barrier further along the journey.

The W3C Web Accessibility Initiative's Easy Checks resource includes keyboard-access checks as an initial accessibility review. It also explains that these checks are not a definitive evaluation. Our proposed application to a commercial prototype is editorial interpretation, not a W3C certification of Global Secure.

Notice where attention moves

In a pointer-based demonstration, the cursor makes the next action obvious to the presenter. A keyboard user needs an understandable indication of the current interaction point. If that indication disappears, the person may have to guess which control will respond.

A practical observation note should therefore record the moment uncertainty begins. The reviewer might identify a menu that opens without an apparent next step, or a help panel from which the return route is unclear. Those descriptions give a team something concrete to investigate.

The note should distinguish the observed behaviour from an assumed cause. A writer can report that the current interaction point was not visible without claiming to know which part of the implementation created the problem. Diagnosis and correction then require the appropriate design and development work.

Include the less polished screens

A review should not stop at the welcome page. Settings, error messages, optional explanations and the way back from a cancelled action are part of the experience. These screens may receive less attention in a promotional demonstration, yet they can determine whether someone finishes the task.

For the hypothetical preference change, consider what happens if the person opens additional information, decides against a change and returns to the original choice. Does the journey still make sense? Can they recognise the existing value? The review should follow those branches rather than assume every user proceeds directly to completion.

Record evidence without inventing a result

A proposed test record could identify the prototype version, task, device setup, observed difficulty and next investigation. That is more useful than a general statement that accessibility has been considered. It also prevents a small preliminary check from being described as proof that the entire product works for everyone.

Different people and assistive technologies can reveal different issues. A keyboard review is one useful part of a wider evaluation, not a substitute for research with the people expected to use the service. No customer-testing results are claimed here.

For UK readers following Shane Ian Murphy's product-development interests, the useful principle is to review the task from the user's route rather than the presenter's preferred route. A design should remain understandable when someone interacts with it differently from the person who built the demonstration.

That changes the design conversation. Instead of asking only whether a screen looks finished, the team asks which routes through it have been examined and what remains to be checked. The answer can guide the next revision without turning an early prototype into an unsupported accessibility promise.

Reference: W3C WAI, Easy Checks — https://www.w3.org/WAI/test-evaluate/preliminary/

Professional information: https://shanemurphy.co.uk/

LinkedIn: https://www.linkedin.com/in/shanemurphy101