Keyboard Users Can't See Where They Are on 11 of 18 College Sites

Ask what’s wrong with a college website and the list gets long fast. Ask what a keyboard user would notice, and one problem comes up more than the rest: they can’t see where they are on the page.

Between July and September 2026, I reviewed 24 public college and university sites against WCAG 2.2 AA as benchmarking work ahead of the Title II deadlines. Five came back clean. One had a single minor finding I didn’t write up. The other 18 had findings worth putting in front of a team, and 11 of those 18 had a problem that left keyboard focus invisible.

These were quick reviews, mostly at the homepage level, and I stopped once I had enough solid findings to write up, usually two to four per site. I did a keyboard-only pass on all of them and used Axe and VoiceOver where they helped. The counts below tell you how many sites had a problem, not how often it appeared on a site.

In July, I wrote about The Same Four Problems, Site After Site: the same four failures kept showing up across public sector and university sites. Those were lost focus, controls with no name, keyboard dead ends, and broken skip links. That was a read from about 30 sites. Counting only the college and university sites surfaces the same four in the same order, now with some stats.

Focus is still first, though calling it the most common failure “by far” may have been too strong. It was an issue on 11 sites vs. 9 for missing names on controls.

Keyboard focus disappears in two different ways

On seven of the 11, a menu, search panel, or overlay stayed open after focus moved past it. At one school, tabbing out of the search panel put focus back on a navigation item the open panel was covering.

On five, a control took focus and showed nothing: a search button, a video control, a row of program links, an Apply Now button. One site had both problems.

If you’re testing with only a mouse, neither problem is likely to show up.

The header is where most of it happens

Thirteen of the 18 had a finding in the primary navigation or the site search, and both sit at the top of every page.

At one school, the search input couldn’t be reached by keyboard at all, so search didn’t work without a mouse. At other schools, the panel opened but focus stayed on the button that opened it, the panel stayed open after the user tabbed past it, or the search field and button had no names for a screen reader.

These aren’t edge cases. They’re in the part of the page almost everyone interacts with.

Controls with no name are nearly as common, and mostly cheap to fix

Nine sites had at least one occurrence.

Five sites had links with no text, including 12 on a single foundation site. The rest were a video iframe, a menu-toggle button, a video button, and a search form. A screen reader announces these as “link,” “button,” or nothing.

Most are small fixes, an attribute or a line of hidden text. The exceptions depend on how the links are templated or on a vendor platform implementation.

Some keyboard problems are about order, not visibility

On some sites, focus went somewhere other than where the screen suggested.

A sidebar dropdown opened and then Tab skipped past its links, so reaching them meant tabbing backward. A Load More button left focus on the button while new cards loaded behind it. Hidden mobile navigation links stayed in the desktop tab order.

Other sites had a menu or search that a keyboard couldn’t fully operate, like a hover-only dropdown holding links that a keyboard user tabs through without seeing any of them.

The smaller patterns were mostly markup, and some sat off the main site

Broken list markup turned up on four sites, and Axe found all four. Contrast failures were common too.

Skip-link problems came in three different forms: no skip link at all, one that stayed invisible when it received focus, and one that landed on an unlabeled close button.

Three sites had the problem on a page hosted outside the main site: a tour-scheduling platform at two, an application page on a separate domain at one.

What the count adds

That earlier post argued these problems are the default outcome of building a site without a keyboard anywhere in the process. The count doesn’t change that, but it does say where to look first.

Put the mouse away and tab through your own header.

On 13 of these 18 sites, that’s where I found something.