Design & UX
By Mike Ritter

Don’t Hijack My Browser

By Mike Ritter

As a person with a disability I find navigating most websites fairly straightforward. I can use the keyboard or a mouse to scroll up and down to view content. With just the space bar I can scroll the page a frame at a time.

Until my browser is hijacked by elements on the page. Then I have to use my mouse to get control of the experience.

Here are four frustrating ways websites hijack my browser.

Search Bar

Hey Google (and now Yahoo!), I’m talking to you!

I get that you want to make it easy for someone to get going on that search, but does my cursor really have to jump to the search box as soon as the page loads?!

You can set up the tab order using tabindex to take the cursor to the box on the tab click.

<input type="text" id="search" tabindex="1">

I get that Google has built this into their system and it’s the expected behavior, but it is a nuisance for people like myself who navigate with our keyboards.

First, it interrupts the browsing flow because I am unable to follow my keyboard shortcut (just backspace on most browsers) to go back a page.

Second, when I start pressing the space bar and want to scroll the page I’m just filling in the search bar. It just doesn’t work.

Confirmation Alert Box

Every now and then I’m surfing the Web and end up on a site with a confirmation box. Sometimes the box pops up on arrival, other times it pops up when I try to leave the page.

I know enough about programming to recognize an opportunity to insert malware. So I never click the confirmation. I don’t know if pressing okay will close the tab or take me to

My remedy is shutting down my browser then reopening it and tromping through history to the sites I had open.

Popup Ads

This one drives me crazy and I’ll wager most developers are guilty of this one.

Attractive popup ads are no longer an annoyance, but part of the business model of many websites. I’m left to watch the popup obscure my content. I get it. The company has to generate revenue. But the ad should get out of my way.

The standard was to timeout the popup years ago. Some ads creatively move to the sidebar in a static ad. Regardless of the technology, this is available functionality. Another former standard was to tie a keyboard shortcut like esc or x to a close function on the popup. But rarely do I see a popup that I don’t have to click an action item or a tiny close link in the top corner with the mouse.

Static Navbar

Finally, there’s the static navigation bar across the top of the page. Sometimes these are three or four lines tall. They are convenient, giving users easy access to site information.

But go back to scrolling.

When I tap space bar on a typical webpage the window scrolls down one frame. This is such a convenient way to quickly browse a page. As I pointed out above, hijacking my cursor gets in the way. But so do those fancy navigation bars.

Some websites account for the navbar adding padding to accommodate the bar across the top. However, plenty of popular websites are oblivious. As the content scrolls, several lines are obscured by the handy bar.

Am I Just a Curmudgeon?

Our lives as developers are already full of UX demands.

Another accommodation now from this guy who just wants to click his spacebar to scroll is not floating to the top of my list.

I get it. But imagine how all of the little tweaks you build into your workflow save you steps and then having to do away with them because somebody else just changed the way things are done. Look at recent decisions by Adobe and Google to shut down services, for example.

For people with mobility impairments, added obstacles to the content are a real barrier. Just getting a mouse cursor in the precise spot can be a chore.

But thoughtful design and graceful transitions can give the browser back to users like myself to enjoy our convenient web experience.

  • Stevie D

    This is where accessibility and usability sometimes clash. The vast majority of people going to Google’s homepage are wanting to type something into the search box – so it’s more helpful for them if that input is given autofocus. I suspect that even when you include people who navigate by the keyboard, the number of visitors to that page who don’t want to type into the search box is insignificantly small. In cases like that, where the change doesn’t make the page inaccessible to those without a mouse, I would say it’s a sensible decision.

    Of course, it does depend what proportion of people are going to go straight to the search box. On a site that has a search box on a general page, where you wouldn’t expect the majority of people to go straight to the search box, it would be unhelpful to give the box autofocus.

    • Thanks for your feedback Stevie. Making those decisions is a delicate balance. Your point about prioritizing whether users are more likely to need the search box off the bat is important. For instance, on the results page, it is likely to scroll those results, but not on the landing page. On most of our sites, autofocus might not be the best tool to get visitors to our content.

  • Joe M

    Everything Mike says is right. As an Australian Government worker we have signed a charter that compels us to make our sites accessible, internally and externally. This includes the code, documents, links, everything. That doesn’t mean boring. It means that for those of us with full functionality it might take an extra click or tab, but for those who are challenged to some degree it let’s them get on with using the site with their browser.
    The W3C should take note of this and provide coding standards that enable the user to control the experience when they need to (maybe they already do, I don’t know).
    The browser challenged may not be as numerous as non challenged. That doesn’t mean it has to be our way.

    • Joe, the Web Accessibility Initiative ( is W3C’s landing for these resources. There are plenty of other resources out there for developers.

      What are Accessibility resources you use in developing Web applications?

  • Jenn

    Totally agree with this post. I really hate Google hijacking my web experience. I despise the auto focus – even if I do want to search I would rather click or keyboard navigate on my own. I also do not life its. Even as a web developer, the first ad-on on any of my machines is ad blocking software then ghostery. Also, flash is disabled by default, as well as cookies (epseically thirs party cookies and Google).

    • Jenn, these are good tips. I’ve found visiting the mobile version of a company’s website from my desktop browser (often at m.sitename.tld) accomplishes these same goals.

  • Well, I’m an idiot and never thought of issues people with disabilities may face online. It makes total sense! Luckily, I’ve avoided most of the pitfalls that you’ve referenced.

    Can you do a post on how to enhance the user experience for those with disabilities? I’d like to know what I can do to make my site better than the rest!

    Great job.

    • Thank you Bobby.

      Fortunately, several templates for the popular content management systems (CMSes) offer accessibility out of the box. WordPress has included the Beez template for years. This is helpful for many employers and designers.

      HTML5 achieves much accessibility too.

      But education on the barriers is important for developers and designers at all levels.

  • Joy

    I have no particular disability that forces me to use a keyboard, and I find all of these things incredibly frustrating, too. Maybe preferring keyboard navigation over reaching for the mouse does put me in a minority, but I’m betting it’s not as small a minority as most developers assume.

  • “Some websites account for the navbar adding padding to accommodate the bar across the top. However, plenty of popular websites are oblivious. As the content scrolls, several lines are obscured by the handy bar.”
    When I read that, of course SitePoint’s navbar was staring at me, so I decided to test how much it scrolls with the space bar (by the way, I didn’t know about that keyboard shortcut, although I should have guessed due to a long history of the Unix “more” command – thanks for that tip!), and… oops – Sitepoint itself is guilty of obscuring a couple lines! It’s a bit translucent, but you still can’t really read underneath there…

    Anyway, I was considering adding a position:fixed navbar to something of mine, but what element should get the padding to make the scrolling work right? The navbar itself is out of the flow, so padding on it has no effect. Padding on the top of the content would just scroll up with the page. Does someone know the trick?

  • Scott

    Come on, really? None of you have heard of the PageDown key, or Alt+Left??

Get the latest in Design, once a week, for free.