A beautiful website still needs to work when the mouse is put away

A website can look finished in a screenshot and still prevent someone from completing an ordinary task. This opinion piece argues that “finished” should include reaching the same task without a mouse.

For a business, that task might be requesting a quote. For a publisher, it might be finding a story, signing in or leaving a comment. The visual design deserves care, but so does the route through the page.

W3C explains that keyboard compatibility enables people to access controls with keys rather than requiring a mouse. This matters to people with disabilities and can also help someone with a temporary limitation or a broken pointing device. [3]

Test a real task

Choose a task a customer would actually attempt. Put the mouse aside and use the keyboard to move through the page.

W3C's preliminary accessibility checks recommend looking for a visible focus indicator, a logical order and the ability to reach and leave interactive controls. A keyboard trap occurs when a user reaches a control but cannot move away from it. [1]

The check is simple to describe. It can be uncomfortable to watch if a menu, calendar or form suddenly makes progress impossible.

Record what you observe without blaming the person doing the test. “The date picker cannot be closed with the keyboard” is a finding a developer can act on. “The customer could not use the site” assigns the problem to the wrong place.

Give the form the same attention as the homepage

W3C's form tutorial explains that labels identify controls and should be properly associated with them. That relationship helps assistive technology identify the field and can enlarge the usable target for a control. [2]

A floating checkbox or a label squeezed into another sentence is more than an untidy detail when it appears at the point where someone must agree, subscribe or save.

A clearly labelled, ordinary form that can be completed deserves priority over an arrangement that requires guesswork. That is an editorial preference, not the result of a measured conversion-rate study.

Ask the customer question before the styling question

In a hypothetical quote form, imagine that a customer has written a detailed description and then encounters an unexplained error. The useful design question is what they need to understand and correct.

Consider how the page identifies the affected field, whether their other information remains available and whether they can return to it. A colour change alone may not explain the problem. Review the experience with people who use different ways of interacting.

A developer's ability to complete a task after learning the page is not enough evidence that a new reader will understand it.

A quick check is a beginning

W3C explicitly warns that preliminary checks do not establish comprehensive accessibility. A page can pass those checks and still contain significant barriers. [1]

Use a short check to find obvious problems, then organise appropriate testing and specialist review. Do not attach a compliance claim to a five-minute exercise.

The accompanying W3C video illustrates keyboard compatibility. It supports the principle; it is not a test of AusLume or another named business.

When planning the next website update, put the customer task in the acceptance criteria alongside the intended appearance. Ask someone to demonstrate the complete route through it. That gives “ready” an observable meaning beyond the screenshot.