Site icon IT & Life Hacks Blog｜Ideas for learning and practicing

How to Improve Keyboard Operation and Focus Indicators｜Practical Web Accessibility for Reducing Hard-to-See Usability Problems

greeden

Green key with wheelchair icon on white laptop keyboard. Accessibility disability computer symbol

How to Improve Keyboard Operation and Focus Indicators｜Practical Web Accessibility for Reducing Hard-to-See Usability Problems

When people think about improving web accessibility, they often focus on issues that are easy to notice visually. But in practice, some problems are hard to see at first glance, yet create a major burden for users. Typical examples are keyboard operation and focus indicators. A page may look natural when used with a mouse, but when someone tries to use it with only a keyboard, problems suddenly appear: they cannot enter the menu, cannot reach a button, or cannot tell where they are. In Part 4, we will focus on these “hard-to-see usability problems” and explain the WCAG 2.2 perspective and practical improvement methods as concretely as possible.

What You Will Learn in This Article

  • Why keyboard operation matters
  • What happens when focus indicators are not visible
  • WCAG 2.2 success criteria related to focus that you should understand
  • Common practical issues and improvement directions
  • How to think about the role division with UUU Web Accessibility Service

First, keyboard operation is not needed only by a small group of desktop users. Many users depend on keyboard navigation, including people who have difficulty using a mouse, people who find precise hand or finger movements difficult, people using assistive technologies, and people who use shortcuts to operate efficiently. There are also many situations where keyboard usability matters even without a special assistive environment, such as using a laptop outside or temporarily operating with one hand. In other words, keyboard operability is not a requirement for only some users; it is a quality issue related to basic web usability.

Keyboard operation here mainly means moving with the Tab key and Shift + Tab, activating items with Enter or Space, and moving through the page using arrow keys when needed. Users need to be able to reach links, buttons, forms, menus, modals, tabs, accordions, and similar elements in order without using a mouse. However, in practice, this basic behavior often breaks because of custom UI or JavaScript implementations that prioritize appearance. For example, something looks like a button but is actually a div element with only a click event, so it does not respond to keyboard input. A dropdown menu depends on mouse hover, so users cannot enter its items with Tab navigation. After opening a modal, focus does not move to the right place and instead escapes to the background. These situations make the page close to “unusable” for some users.

Alongside keyboard operation, focus indicators are also important. Focus refers to the element currently targeted by keyboard operation. With mouse operation, users can visually track the cursor position. With keyboard operation, the focus indicator tells users “where they are now.” Therefore, when users move to a link or button, the current position must be clearly shown through an outline, background-color change, underline, shadow, or similar visual cue. If there is no focus indicator, or if it is extremely faint or blends into the background, users cannot understand which item they are about to operate. This is not merely a visual design issue; it affects whether operation itself can be completed.

In WCAG 2.2, focus-related requirements have been strengthened compared with earlier versions. In practice, the especially important criteria are 2.4.11 “Focus Not Obscured (Minimum),” 2.4.12 “Focus Not Obscured (Enhanced),” and 2.4.13 “Focus Appearance.” These require that the focused element not be hidden when users move with the keyboard, and that the focus indicator itself be sufficiently visible. WCAG already required focus to be visible under 2.4.7 “Focus Visible,” but WCAG 2.2 goes further and addresses practical problems such as “it is technically visible, but hard to recognize” or “it is hidden behind a fixed element.” This is one of the very practical aspects of the update.

For example, many modern websites use a fixed header at the top of the screen. Because menus and contact buttons remain visible while scrolling, this can feel convenient for mouse users. However, when someone navigates the page with a keyboard, the link or input field that receives focus may be hidden behind that fixed header. The user keeps pressing Tab, but visually it seems as if nothing is happening, and they cannot tell where they moved. This is exactly the kind of situation addressed by 2.4.11. A UI that looks convenient during design can reveal a completely different side when checked with keyboard navigation.

Another common issue is that the focus indicator itself is extremely weak. In an attempt to preserve visual consistency, some sites remove the browser’s default outline and replace it with a very pale gray border or a shadow that is barely noticeable. Creators may think “we are showing it,” but if the contrast against the background is low or the change is too small relative to the element size, users may not notice it in practice. In navigation areas with many links, table-style data, card lists, and similar layouts, unclear focus indicators greatly increase operation difficulty. Focus indicators are not decoration; they are navigation cues. Rather than worrying that they stand out too much, we should prioritize not letting users lose their place.

The first practical check is whether users can move from the beginning to the end of a page using only the Tab key. Check whether major interactive elements can be reached in order: header, global navigation, breadcrumbs, main content, sidebar, forms, and footer. At this time, it is also important to check whether the navigation order deviates significantly from the visual flow, whether focus disappears midway, whether elements that should receive focus actually do, and whether meaningless decorative elements receive focus too often. A major advantage of keyboard testing is that it can be started without any special testing environment. Simply putting the mouse aside and using the site with the Tab key can reveal many issues.

One point to watch carefully is focus order. Even if every element can receive focus, operation becomes difficult if the order is unnatural. For example, before moving from the top menu to the body text, focus may jump to links in invisible areas or detailed sidebar items. Or within a card UI, focus may move in an order such as title, image, detail link, and blank space, making it hard to understand which information forms one group. This kind of order disruption can easily occur due to HTML structure, CSS presentation, or JavaScript control. It is important to check whether the visual order and the source structure or operation order are not too far apart.

Skip links also affect the comfort of keyboard operation. On sites with large headers or many navigation links, users may have to pass through many small links from the beginning of the page every time before reaching the main content. Therefore, it is very effective to provide a skip link such as “Skip to main content,” allowing keyboard users to move directly to the main content. Skip links do not need to stand out normally, but they must be clearly visible when focused. Even if a skip link is installed, it will not function if it remains off-screen when focused or blends into the background. Here again, focus indicator design is important.

Components involving JavaScript, such as modals, drawer menus, and tab UIs, require special care. When a modal opens, does focus move to the heading or close button inside the modal? When it closes, does focus return to the original trigger button? When a drawer menu is open, does focus escape to the background content? In a tab UI, can users tell which tab is currently selected, and does it support expected operations such as arrow-key movement? Visual polish alone is not enough. The key question is whether the operation flow feels natural to keyboard users. Modern sites increasingly use animated and dynamic UI, but maintaining the user’s operational context is even more important.

Even in smartphone-centered design, the keyboard operation perspective is not irrelevant. When considering tablets with external keyboards, some assistive technologies, TV browsers, and special input devices, operability through keyboard or keyboard-like sequential navigation remains important. Clear focus indicators also help not only keyboard users, but anyone who may easily lose track of the current operation target. In other words, strengthening focus indicators is not a niche fix; it improves overall operation quality.

Here are some common “almost good, but not quite” examples in practice. First, users can move to global navigation links with Tab, but submenus do not open with the keyboard. Second, buttons can receive focus, but the current position is shown only by a tiny background color difference and is almost invisible. Third, before reaching the inquiry form, users must tab through many SNS links and banners, making the main content feel far away. Fourth, fixed headers hide form fields or error messages, making the focus position hard to understand. Fifth, in complex UI such as carousels and accordions, items look selectable but cannot be reached with the keyboard. All of these are hard to notice with mouse operation, but cause major stress with keyboard operation.

As for improvement, the foundation is to use native HTML elements correctly. Use a elements for links, button elements for buttons, and appropriate input elements for form controls. This alone greatly improves compatibility with keyboard operation and assistive technologies. In addition, do not casually remove the browser’s default focus indicator; if you remove it, design an alternative that is even more visible. Adjust scroll positions so fixed headers and sticky elements do not hide focused items. Provide skip links. For modals, tabs, and similar components, align behavior with WAI-ARIA concepts. Rather than adding flashy new features, preserving basic operation has much greater value.

Here, let us also organize the compatibility with UUU Web Accessibility Service. Services like UUU, which provide viewing support functions such as font-size changes, contrast adjustment, line-height adjustment, animation stopping, read-aloud, translation, and furigana display, have great value in helping users adjust pages into a more visible and understandable state. For example, if a focus indicator is hard to see because of a small color difference, contrast adjustment may help as a supplementary measure. Read-aloud support and display adjustments may also improve overall understandability.

However, whether keyboard operation itself works, whether focus order is appropriate, whether focus is not hidden, and whether users can move properly inside modals cannot be fundamentally solved by viewing support functions alone. Those areas require improvement of the original HTML structure, CSS design, and JavaScript implementation. In other words, services like UUU are highly compatible with the role of “supporting visibility and readability,” while the quality of keyboard operation and focus management itself remains an area that creators must implement responsibly. Understanding this role difference helps avoid misunderstandings such as “we installed a tool, but the site is still hard to operate.”

This topic is not only for engineers. Directors can include checks such as “Can users reach major paths using only the keyboard?” and “Is focus sufficiently visible?” during requirements definition and acceptance testing. Designers can treat focus indicators as design targets from the beginning, just like default states and hover states. Editors and public relations staff can also notice issues such as skip links, navigation organization, and excessive unnecessary links. In other words, keyboard operation and focus indicators are implementation details, but they also reveal the design philosophy of the entire site.

This concludes Part 4. Keyboard operation and focus indicators are hard to notice visually, but they are extremely important elements that determine whether users can actually use a website. WCAG 2.2 places greater emphasis not only on focus being visible, but also on it being sufficiently recognizable and not hidden by fixed elements or similar UI. In practice, the first step is to operate the page using only the Tab key and check order, reachability, visibility, and the behavior of modals and menus. Services such as UUU Web Accessibility Service are valuable for viewing support, but the quality of keyboard operation and focus management still needs to be improved through the design and implementation of the web content itself. Next time, we will look at how to improve difficult-to-read text, focusing on headings, summaries, and plain Japanese.

Reference Links

Exit mobile version