Pop-ups, why not use them?

[Stomme poes]

Ah. I don't disagree with that. And the most recent popup thread had plenty of people starting out with "popups eat our children" and then link to some other solution that the OP might not have thought of.

[adh32]

I find popups quite handy in certain situations. Say you are filling in a form and don't understand what to put in that field. Sometimes there's a link to click for more info, and it pops up over the page.

I think that pop-ups used in that scenario should respond to hover/focus rather than a click/keypress. Either that or make their function obvious. Simply because people might be reluctant to click a link (if its function isn't clear) while completing a form for fear of losing what they've typed.

Woe be the day when some HTML5 crap starts building those in so I can't block them, like they're doing now with autofocus and auto-fill in forms.

Autofocus might be the most stupid HTML5 thing that I've yet seen.

Unless you use Javascript to specifically move the focus over to the popup, the keyboard focus is still on the page underneath. I've tested the generic Lightbox2 that uses jQuery and while after clicking a thumbnail I *do* have the ability to use the keyboard to do things like next and prev image and closing the thing, my TAB remains on the page underneath. This breaks the rules of modals: user should have no access to the page underneath until some decision has been made in the modal (such as what happens with alert() and confirm() popups).

I agree about the focus issue and it seems logical to move focus, but it raises questions of its own, like: is the change of focus announced, or assumed by the user if the ARIA role is understood? Or might it cause a problem? Or not?

Talking of such problems (and getting my comment on topic), isn't there an issue of context with window pop-ups and screen readers? If what I've read is correct, that alone is a good reason to very much limit their use.

[gary.turner]

Side-by-side comparison should be natively implemented by the website, though. Why so few sites have this feature is beyond me.

Should be is nice, but is is what is.

cheers,

gary

[C. Ankerstjerne]

Very true. And while lack of side-by-side comparison is an excuse for user-written scripts of various kinds, it's not an excuse for the site to start making pop-ups.

[Stomme poes]

I think that pop-ups used in that scenario should respond to hover/focus rather than a click/keypress. Either that or make their function obvious. Simply because people might be reluctant to click a link (if its function isn't clear) while completing a form for fear of losing what they've typed.

We had/have links in our form that go to whole new pages, or open PDFs (I've tried to change these back to HTML pages as much as possible).

This is because people, given the opportunity to read something first, or just start filling in the form, will fill out the form first. Then they get to a question asking about something they have no idea what it is, and need the help text. I am a firm believer in forms only containing form elements, but with our insurance forms, help text was necessary.

It works on focus/hover, but our testers tended to click on them (because that's what every other web site does), meaning they went to a whole new page without realising they would.

When they hit the back button, their form info might be gone (if browser caching was turned off).

So we added target="blank" to those links. The ones that only had help-text (no link to other page) went to #void, so users clicking on them did not get a page refresh, brought to teh top, or anything else. I believe one of the usability failures in our forms is, you can't tell which help texts are links and which aren't (the "popup" says something like "opens in new window" but then in most browsers it doesn't anyway, bleh).

We were also forced to do the same for all pdf links. Everyone who tested expected the PDFs to open in new windows or new tabs, so when ours didn't, they closed the browsers by accident. Every time. Meh.

There was no reason to have the help text in an actual popup, but it made a LOT of sense for any new pages to be separate in some way. This retained unsubmitted form data in all browsers whether the user had caching on or not, and some of our forms are really, really long.

If the "new pages" were short enough, they probably would have been some kind of popup window, but I found it easier to link to the relevant part of the page (if the user needed to know the difference in the types of coverage, I sent them to the "Coverage" page with a hash to specifically the types of coverage).

is the change of focus announced, or assumed by the user if the ARIA role is understood? Or might it cause a problem? Or not?

If the ARIA role(s) are understood, they are supposed to deal with that (the role tells the AT whether it should be in focus mode (role="application" does this, it's kinda like forms mode, so users' keystrokes edit and select stuff rather than navigation/reading) or in a reading mode (role="dialog" or role="alertdialog" are supposed to do this I think), whether focus or navigation is allowed outside that area, and supposed to let both the user and the AT know what's going on.

You would also have a role on whatever the user is clicking on to initiate the dialogue.

Without ARIA, or with sighted keyboarders, I'm still leaning towards JS manually moving focus to the dialogue box and not allowing it out until the user has dealt with that box. Then you'd manually have to put the focus back when they are done, either exactly where they were when they triggered the event or right after it. I actually don't know what the best way is to do this, and the idea of hijacking the tab key makes me uneasy, but that's due to my not being an application developer.

[AussieJohn]

When someone says "I want to cut my own head off" and one person say "that will be painful and cause your death" and the OP says "Yeah but I really wanna, it's a science experiment" then we've done our job and now anyone who wants to explain to the poor sod how to cut his damn head off, do so. We're not required to spend 16 out of the 20 responses on how much it really sucks to have your head cut off, are we?

I tried this once. It was an unpleasant experience.


Lightboxes are probably the new pop-ups. While I agree that when they are prompted (e.g. image gallery, et al) I'm quite happy to use them. When I land on a page and as soon as I interact with it, a modal lightbox pops up and offers me something retarded I want to scream at the idiots who decided that every user on the site needed to have their experience screwed up.

I'm with Stomme Poes on this one, next time I see an uninvited Lightbox or popup I'm going to email them (and link them to this thread ).


I'm also hanging out for ARIA roles to actually work better so that we might script our web applications nicely (and have modals be modals, etc.)

On to browser popups. User confusion and valid use-cases aside...

It irks me, being brought to a new (popup) window for functionality that can be inside of the webpage. Argh.

Popups are right up their with target="_blank" for all external links as one of my pet peeves. (Clients reaaally hate the possibility of someone leaving their site. Dear clients, It's called a *back button* ).Taking the choice of the next action away from users is bad, it makes me sad (and sometimes mad).


I feel like I'm ranting and not making too much sense. So I'm going to stop now