Surfing the Web Without a Mouse: A Keyboard Accessibility Investigation
Introduction
For most internet users, the mouse or touchpad is an essential part of navigating the web. Whether we are searching for information, watching videos, writing assignments, or designing websites, clicking and scrolling have become such ordinary interactions that we rarely stop to consider them. However, for individuals with certain physical disabilities, neurological conditions, or temporary injuries, using a mouse may not be possible. Instead, these users may rely on a keyboard to navigate the internet and accomplish the same tasks.
Although accessibility standards such as the Web Content Accessibility Guidelines (WCAG) establish that websites should be operable through a keyboard, the extent to which websites actually accommodate keyboard users can vary significantly. A website may technically support keyboard navigation while still making simple tasks unnecessarily difficult. In other cases, functions that seem straightforward with a mouse may be difficult to discover or operate without one.
For this investigation, I chose five websites that are relevant to my everyday academic and personal activities: Davidson College, Google Docs, YouTube, Cargo, and Overleaf. I wanted to understand not only whether these websites provide keyboard alternatives, but also how efficiently users can navigate them and whether their accessibility features are easy to discover. The following sections examine the keyboard interactions documented for each website, the accessibility advantages they offer, and the potential difficulties that require testing.
My General Experience
Before looking at individual websites, I wanted to understand how much of the keyboard-only browsing experience depends on the browser itself.
I primarily use Google Chrome, which provides several shortcuts that make navigating the browser possible without a mouse. For example, Ctrl + L moves focus directly to the address bar, Ctrl + T opens a new tab, Ctrl + Tab switches between open tabs, and Ctrl + W closes the current tab. These shortcuts allow users to complete many ordinary browser interactions without navigating through several buttons.
One important difference between using a mouse and using a keyboard is how users move between interactive elements. With a mouse, I can select almost anything visible on the screen immediately. Keyboard navigation, however, usually follows a predetermined sequence. Pressing Tab moves focus to the next interactive element, while Shift + Tab moves backward.
This makes the organization of a website particularly important. A page with dozens of links, buttons, and menus may be perfectly manageable with a mouse but exhausting to navigate through Tab alone. The experience also depends on whether the currently selected element is clearly highlighted. Without a visible focus indicator, users may not know which button will respond when they press Enter.
Another important distinction is between navigating a webpage and interacting with an application embedded within it. For example, the Tab key might move between buttons on a traditional website but perform a completely different function inside a text editor. This creates situations where users need to understand not only which shortcuts are available, but also which part of the interface currently has focus.
Davidson College
As a student at Davidson College, one of the first websites I wanted to investigate was the Davidson College website. I frequently use the college’s online resources to access academic information, find departmental webpages, and learn about campus services. Consequently, the website’s accessibility has direct implications for how easily students can access essential information.
One of the most useful accessibility features Davidson documents is its skip-to-main-content option. On websites with extensive navigation menus, keyboard users may otherwise have to press Tab repeatedly before reaching the actual content of a page. A skip link allows users to bypass these repetitive links and move directly to the information they need.
This is especially useful on a college website, where students may visit several pages during a single browsing session. Without a skip link, navigating between departments, academic resources, and campus information could involve repeatedly moving through the same menus.
Davidson’s website also identifies structured headings, alternative text for images, and keyboard navigation as important features of its website. Together, these features indicate an effort to accommodate users who interact with webpages differently.
One area I would particularly like to evaluate is the consistency of this feature across different pages. A skip link is most useful when it is available throughout a website rather than only on its homepage. Similarly, keyboard focus should remain visible as users move between links and buttons.
Overall, Davidson’s published accessibility features suggest that the college has considered the needs of keyboard users.
Google Docs
Another website I investigated was Google Docs, which I regularly use for academic writing, college projects, and preparing assignments.
Unlike a traditional webpage, Google Docs is a complex editing environment. Users must be able to write text, format paragraphs, insert images, leave comments, and navigate several menus. Making these interactions accessible through a keyboard presents a considerable design challenge.
One particularly useful feature is Google Docs’ Tool Finder. By pressing Alt + / on Windows, users can open a search field and type the name of an action they want to perform. For example, rather than navigating through several menus to insert an image, a user can search for the relevant command directly.
This is a significant accessibility advantage because it reduces the number of sequential interactions required to perform a task. Instead of relying entirely on Tab to move through the toolbar, users can search for the function they need.
Another feature I found particularly interesting was Google Docs’ support for keyboard-based image editing. For example, pressing Ctrl + Alt + Y on Windows while an image is selected opens the alternative-text editor. This allows users to add descriptions to images without having to right-click them.
This is important because alternative text is itself an accessibility feature. It allows people using screen readers to understand the content of images. Making the process of adding alternative text accessible through the keyboard therefore helps users create more accessible documents.
Google Docs also provides keyboard shortcuts for working with comments. When navigating comments, users can use J and K to move between comments, R to reply, and E to resolve them. These commands are particularly useful in collaborative academic environments, where responding to feedback is an important part of the writing process.
Although Google Docs provides extensive keyboard functionality, it also raises an important question about discoverability. A user like me who already knows these shortcuts may find the application efficient, but someone unfamiliar with them may struggle to locate less commonly used commands.
Fortunately, Google Docs includes a keyboard shortcut reference, accessible through Ctrl + /. The combination of direct shortcuts, searchable commands, and a shortcut reference makes Google Docs a strong example of how complex applications can support keyboard users.
YouTube
I also wanted to investigate YouTube, since watching videos involves a different set of interactions from reading webpages or editing documents.
YouTube provides a surprisingly extensive collection of keyboard shortcuts. For example, pressing K plays or pauses a video, J and L move backward and forward by ten seconds, M mutes or unmutes the video, and C enables captions when available. Users can also press the slash key to move directly to the search field.
These shortcuts can make video navigation much more efficient. Instead of repeatedly pressing Tab to reach the playback controls, users can perform common actions with a single keystroke.
Get Abkamran’s stories in your inbox
Join Medium for free to get updates from this writer.
YouTube also provides a keyboard shortcut menu, accessible through Shift + ?, which helps users discover commands they may not already know.
However, one aspect of YouTube’s keyboard design is particularly interesting. However, I discovered that certain shortcuts require the video player to have focus before they will work.
This creates a potential problem for keyboard users. Someone may know that K pauses a video but find that pressing the key does nothing because focus is currently somewhere else on the webpage.
For a mouse user, moving focus to the player is relatively straightforward. For someone using only the keyboard, however, determining where focus is located and how to move it can require additional effort.
This highlights an important distinction between making a shortcut available and making it intuitive. A keyboard shortcut is only useful if users understand when it can be activated.
One possible improvement would be to make the current focus state more obvious or provide clearer instructions when playback shortcuts are unavailable. This would help users understand why a command is not responding.
Overall, YouTube provides a strong collection of keyboard controls, but its focus-dependent shortcuts demonstrate how accessibility can be affected by seemingly small interaction decisions.
Cargo
One of the websites I was particularly interested in investigating was Cargo, a platform I have used to create and design websites for clubs.
Cargo is different from the previous websites because its interface emphasizes visual manipulation. Users can rearrange pages, edit images, and adjust layouts by interacting directly with elements on the screen.
This presents a particular challenge for keyboard accessibility. Many visual design tools rely on dragging, double-clicking, or right-clicking, interactions that may not have obvious keyboard equivalents.
For example, I discovered that pages can only be reordered by clicking and dragging them into a new position. Similarly, page titles can be renamed by double-clicking, while additional editing options can be accessed by right-clicking.
These interactions are intuitive when using a mouse, but they raise questions about how users who cannot use a pointer are expected to accomplish the same tasks.
I was also interested in Cargo’s image-caption workflow. Adding captions to images is something I frequently do when designing websites, so I wanted to see whether I could accomplish this using only my keyboard. Normally, Cargo allows users to right-click an image or video to access the option for adding a caption. However, without a mouse, this interaction becomes considerably more complicated.
One possible alternative is Shift + F10, which opens context menus in some applications. However, this shortcut does not work with custom menus like Cargo’s. This highlights a potential accessibility problem: while adding a caption is a relatively simple task for someone using a mouse, keyboard users may have difficulty accessing the same functionality. Cargo could improve this experience by making the caption option accessible through Tab navigation or by providing a dedicated keyboard shortcut.
The broader concern is that accessibility should apply not only to websites that people visit, but also to the tools used to create those websites.
If a user cannot rearrange pages, edit images, or access essential design controls without a mouse, they may be excluded from participating fully in web development.
A useful improvement would be to provide clearly labeled keyboard alternatives for dragging elements, renaming pages, and accessing editing menus. For example, a selected page could potentially be moved using arrow keys or dedicated move-up and move-down commands.
Overleaf
The final website I investigated was Overleaf, an online LaTeX editor used for creating technical and academic documents.
Overleaf combines several different interfaces within one webpage, including a project list, source-code editor, compilation controls, and PDF preview. This makes keyboard navigation particularly important because users frequently need to move between different parts of the application.
One feature that stood out in Overleaf’s documentation is the behavior of the Tab key inside its source editor. Rather than moving focus to the next interactive element, Tab is used to indent code, while Shift + Tab removes indentation.
This is useful when writing LaTeX because indentation helps organize source code. However, it also creates a potential conflict with ordinary webpage navigation.
On most websites, pressing Tab moves focus to the next button or link. In Overleaf’s editor, the same key performs an editing function. Someone unfamiliar with the application might therefore struggle to understand how to move from the source editor to other controls.
Fortunately, Overleaf provides shortcuts for several important actions. For example, users can compile their documents using Ctrl + Enter or Ctrl + S on Windows, with corresponding Command shortcuts on Mac.
This reduces the need to navigate directly to the Recompile button, which is useful for keyboard users.
However, these shortcuts raise a similar question to the one encountered with Google Docs: how easily can users discover the available commands?
If a user already knows the compilation shortcut, the process may be straightforward. Someone unfamiliar with Overleaf, however, may not immediately understand how to access the controls outside the editor.
A useful improvement would be to provide clearer keyboard instructions for moving between the source editor, project navigation, and PDF preview. This would make the application more approachable for users who are unfamiliar with its interaction model.
Conclusion
After examining how different websites accommodate keyboard navigation, I realized just how much I take the convenience of a mouse for granted. Tasks that ordinarily require little thought can become considerably more complicated when the ability to click, hover, or drag is taken away. What surprised me, however, was that some websites actually offered more efficient ways of completing certain tasks through keyboard shortcuts. The experience was therefore not uniformly frustrating; rather, it revealed how differently websites approach accessibility and how much those decisions shape the experience of using them.
I also realized that the browser itself can only do so much. Although browsers provide the basic tools necessary for keyboard navigation, individual websites ultimately determine how useful those tools are. A well-designed interface can make navigating without a mouse relatively straightforward, while a poorly designed one can make even the simplest tasks unnecessarily difficult. This is particularly concerning when the websites in question are used for education, communication, or creative work, where access is not simply a matter of convenience.
Ultimately, this investigation made me think more carefully about who we imagine as the user when designing digital interfaces. For those of us who can comfortably use a mouse, accessibility problems are often invisible because we never encounter them. Yet for people who depend on alternative methods of navigation, those same problems can determine whether they are able to participate independently in an increasingly digital world. As designers, we should not wait until someone encounters these barriers to begin thinking about accessibility. It needs to be considered from the very beginning of the design process.
