Popups, web applications, accessibility

[Harlan Messinger]

Can you help me figure out what to do about popups?

Sometimes we develop web applications where popups make very good sense for
precisely the same reasons they make sense in traditional locally-installed
application interfaces. I understand some people object, on grounds having
nothing to do with disabilities, to links that generate new browser windows.
I don't know what the basis of their objection is, but I wonder whether the
same people object every time their word processing application prompts them
for information with dialog boxes (for font selection, saving the file, and
so forth) rather than removing their document from the main window and
replacing it there with the prompt. Or whether it bothers them that the Help
command launches a separate window rather than, again, replacing the
document they're working on with the Help content.

Anyway, popups are useful for web-interface applications for exactly the
same reasons. But now, learning about accessibility issues, I have read that
popups are troublesome for people using adaptive software for visual
impairments. I would have thought that it might suffice to provide a
positive indication to such users that a link will open a separate window,
to indicate in the new window that it *is* a new window, and to provide a
message in the new window indicating that it should be closed to return to
the main window.

Apparently, that's not enough, and popups aren't allowed. Trying to find out
*why* there's an outright ban, I found in Google Groups a posting explaining
that, "It is a royal pain in the posterior to find your way back to where
you started when sites start spawning new windows. In MS Windows, you
cannot assume that when you kill the new window (Alt-F4 or whatever) you
will go back to the previous windows. The OS might decide to give the
desktop the focus, for example."

If I provide cues such as those I mentioned above, is this the sole
remaining objection? If so, can this be overcome by placing a link at the
top of the popup that reads, "Return to main window", and which uses script
to explicitly activate the main window before closing the popup?

Theoretically script is also not allowed--but I had understood that that was
only if it caused changes in the interface that weren't discernible to the
disabled user. The use of script here is specifically to *make* a change
discernible to the user. Does that change things?

If none of these considerations is sufficient to override the general ban on
popups, then what does one do instead, keeping in mind that the application
*also* has to operate in a manner that will be intuitive to the sighted
user?

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Nick Kew]

In article <bm************ @id-114100.news.uni-berlin.de>, one of infinite monkeys
at the keyboard of "Harlan Messinger" <h.*********@co mcast.net> wrote:

Sometimes we develop web applications where popups make very good sense for
precisely the same reasons they make sense in traditional locally-installed
application interfaces.
Fair enough so far. I agree they're appropriate in some circumstances.
I understand some people object,
To popups in general, or yours in particular? They get a bad name on the
Web because thare are far more examples of abuse than of good use.
Of course I can't say which category yours fall into.
Anyway, popups are useful for web-interface applications for exactly the
same reasons. But now, learning about accessibility issues, I have read that
popups are troublesome for people using adaptive software for visual
impairments. I would have thought that it might suffice to provide a
positive indication to such users that a link will open a separate window,

But that's exactly what the WCAG says: don't open new windows without
warning the user in advance! If people object, either you're doing something
else wrong (maybe *how* or *when* you open popups) or someone is being
overly dogmatic.

I suggest you read the WCAG and perhaps browse or join relevant mailinglists,
rather than rely on what may be a suspect source.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Stanimir Stamenkov]

Harlan Messinger wrote:

Well, imagine the word processing analogy, where your document disappears
every time you want to change your font, and is replaced by the
font-changing interface. Then, to see the effect of your change, you have to
click OK and wait till your document redisplays. If you don't like the
result, you have to open the font display all over again.

Well, in the context of a web browser what prevents the user of
opening a second window with the "Change Font" interface document on
his/her demand?

--
Stanimir

[Alan J. Flavell]

On Fri, 17 Oct 2003, Harlan Messinger wrote:

[re: acronym]

Since it's an ordinary English word, and they discuss it alongside
"abbreviati on" (granted that they misinterpret the distinction between the
two), maybe they felt their examples established the usage well enough.
You might find the discussions on record which went on during the
drafting of HTML4. I followed them (and occasionally put my spoke
into the discussion...) at the time.

I think the outcome of the discussion (against my wishes and those of
a minority of others) could be crudely summarised as: "everyone knows
what an acronym is - the discussions have shown that individuals agree
that everyone should know what an acronym is - just that their
definitions are incompatible with each other! So, we 'solve' the
problem by tossing the mutually-incompatible examples into the
specification, and leaving the users of HTML4 to work something out
for themselves."
seems clear enough to me what the intent is,
Does it? I think I'd have to refer you back to the drafting
discussions. This has also been discussed here, several times since,
and I've no Round Tuits left for doing it again.
and it works
With the greatest of respect, you seem to be taking a particularly
narrow view of "works", even by the standards of previous discussions
on the topic.
in the current Netscape and IE versions. I've read that it's useful
for table headings, as well, when the text that ought to be read by
the speech synthesizer is somewhat different from what's being
displayed for sighted readers.
I have this hunch that you're describing a productive use of the
"title=" attribute in HTML4 - by no means confined to the "acronym"
element.

[...] According to W3C, <dfn> indicates that its content is the "defining
instance", whatever that means. It doesn't provide a means to display the
term on the page while providing access (through a bubble or a link) to its
definition.

Well, this is funny: in spite of the W3C's failure to point out that <dfn>
works this way, it works just like <acronym>, if you give it a title, in
both Netscape 6 and IE 6,
Why ever not? The "title=" attribute is a general HTML4 thing, it
"works" (in the sense that you mean here) on every element which the
browser recognises.

[ re: <abbr> ] FWIW, I don't understand why even as late as IE6 this is omitted. The
similar tags (<acronym>, <dfn>) are supported.

The dominant vendor doesn't need to worry about interworking
specifications, except where the specifications are imposed by
legislation. History is full of examples. Occasionally they'll deem
it in their interest to conform, in some narrow area, and make a great
song and dance about it for a while, but mostly they sweet-talk their
customers into the belief that the majority vendor is better because
it's different.

The reason that IE does not respond to <abbr title="..."> has nothing
to do with some erroneous belief that title= is specific to <acronym>,
<span>, (and <dfn> as you've now discovered). The real reason is that
IE does not choose to recognise <abbr...> at all, and in consequence
it disregards all attributes and styles applied to it, just as it
would disregard the attributes and styles applied to some non-existent
<foo> or <furble> tag.[1]

On the other hand, IE, just like WWW-conforming browsers, has support
for title= attribute on a whole range of tags which it _does_ support.
Try it and you'll see.

all the best

[1] OK, it doesn't _have_ to be that way. A browser _could_ choose to
implement the non-existent <furble> tag by assigning it no particular
properties of its own, but nevertheless honouring whatever properties
or behaviours were attached to its attributes and styles. Do any
browsers actually do that? I don't recall meeting one.

[Stan Brown]

In article <1b************ *************** *****@4ax.com> in
comp.infosystem s.www.authoring.html, Stephen Poley
<sb************ ******@xs4all.n l> wrote:

But if there is an *objective* reason why all pop-ups are bad, I would
also be interested in knowing what it is.

I think I can suggest two such reasons. The first: what does an
aural browser do with a popup? Can a visually impaired user "see"
the popup window? I rather doubt it. The second reason flows from
current practice by users.

Popups are often abusive; I think we can all agree on that.

Therefore many of the people who have the option have disabled
popups. (Unfortunately this often means disabling _all_ popups. For
instance, Mozilla changed behavior between 1.2 and 1.4 so that
"Block unrequested popups" now blocks many that I used to get by
clicking on links in 1.2.)

Therefore popups will not be seen by a significant minority of
users. From their point of view, they click on a link and nothing
happens.

Therefore, anything that depends on popups to present content is
bad, because a number of users won't see the content.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Alan J. Flavell]

On Sat, 18 Oct 2003, Stan Brown wrote:

Popups are often abusive; I think we can all agree on that.

I think many of _us_ could agree on that, indeed: but the truth is
that it matters rather little what _we_ think: the important thing is
what our readers think. And my understanding is that web users
dislike unsolicited pop-ups, particularly because they associate them
with intrusive advertising that only distracts them from what they
were trying to do.

(It just so happens that I feel the same way about it, but it would
make little difference in web authoring terms just _what_ I,
personally, thought about it.)

Even _solicited_ ones can be hard to use, if they aren't carefully
designed. Have you ever tried chasing down a three-level pop-up menu
using one of those nipple things on the IBM laptop? It's a pain.

cheers

[Nick Theodorakis]

On Sat, 18 Oct 2003 17:14:14 +0100, "Alan J. Flavell"
<fl*****@ph.gla .ac.uk> wrote:
[...]

[1] OK, it doesn't _have_ to be that way. A browser _could_ choose to
implement the non-existent <furble> tag by assigning it no particular
properties of its own, but nevertheless honouring whatever properties
or behaviours were attached to its attributes and styles. Do any
browsers actually do that? I don't recall meeting one.

A quick test (on Win98) indicates that Mozilla 1.4 and Opera 7.1 will
assign CSS properties to an imaginary tag <furble>, and Mozilla will
furthermore pop up a "tooltip" in response to a title attribute to the
said <furble> tag.

Nick

--
Nick Theodorakis
ni************* *@hotmail.com
nicholas_theodo rakis [at] urmc [dot] rochester [dot] edu

[Alan J. Flavell]

On Sun, 19 Oct 2003, Nick Theodorakis wrote:

On Sat, 18 Oct 2003 17:14:14 +0100, "Alan J. Flavell"
<fl*****@ph.gla .ac.uk> wrote:

implement the non-existent <furble> tag by assigning it no particular
properties of its own, but nevertheless honouring whatever properties
or behaviours were attached to its attributes and styles. Do any
browsers actually do that? I don't recall meeting one.

A quick test (on Win98) indicates that Mozilla 1.4 and Opera 7.1 will
assign CSS properties to an imaginary tag <furble>, and Mozilla will
furthermore pop up a "tooltip" in response to a title attribute to the
said <furble> tag.

Thanks for the correction! I must remind myself not to make
broad-brush statements based on out-of-date tests.

cheers

[Stephen Poley]

On Sat, 18 Oct 2003 16:14:55 -0400, Stan Brown
<th************ @fastmail.fm> wrote:

In article <1b************ *************** *****@4ax.com> in
comp.infosyste ms.www.authoring.html, Stephen Poley
<sb*********** *******@xs4all. nl> wrote:

But if there is an *objective* reason why all pop-ups are bad, I would
also be interested in knowing what it is.
I think I can suggest two such reasons. The first: what does an
aural browser do with a popup? Can a visually impaired user "see"
the popup window? I rather doubt it.

So do I. I don't know much about aural browsers, but I would have
expected that they would simply ignore the target attribute, so using it
should not cause the reader any inconvenience.

The second reason flows from
current practice by users.

Popups are often abusive; I think we can all agree on that.
Sure.
Therefore many of the people who have the option have disabled
popups. (Unfortunately this often means disabling _all_ popups. For
instance, Mozilla changed behavior between 1.2 and 1.4 so that
"Block unrequested popups" now blocks many that I used to get by
clicking on links in 1.2.)

Therefore popups will not be seen by a significant minority of
users. From their point of view, they click on a link and nothing
happens.

That sounds to me suspiciously like broken browser behaviour. If the
user has disabled pop-ups, then clicking on a link which makes use of
the target attribute should simply cause that attribute to be ignored
(and probably also any 'onclick' Javascript) and the linked page to be
opened in the current window.

So then we get into the perennial debate as to how far one goes to cope
with broken browsers.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[Philipp Lenssen]

Alan J. Flavell wrote:

For abbreviations, I'd use <abbr>, and then (if I'm feeling generous
on the day) wrap that in a <span class="abbr"> for the benefit of the
benighted users of that unjustly-popular non-WWW-conforming
browser-like operating system component. Assigning both tags an
appropriate "title=" attribute.

Then the stylesheet can contain stuff like

abbr, span.abbr { ... }

so that it comes out OK.

I use <acronym> because the display of title-text as pop-up-text is
broken in IE for <abbr>. It is not for <acronym>. The largest
percentage of browsers used to access my websites (and those of others,
I guess) is IE.
Theoretically I agree, and prefer <abbr> because how something is
read-out (whether as one word or separate letters) is more or less
presentational, and basically I believe the W3C is confusing the two as
well.

[1] The HTML4 spec makes no attempt to define the term "acronym", but
their examples are at variance with dictionary definitions and with
serious usage. "F.B.I" (with dots!) an acronym - my foot!

Exactly.

--
Google Blogoscoped
http://blog.outer-court.com

[Philipp Lenssen]

Harlan Messinger wrote:

[On opening a link in a new window based on user choice]

Actually--and years of experience with users of all kinds of
applications back me up on this--I know well enough that many people
don't have the slightest idea about some of the features available to
them that you and I take for granted, beyond those that are visible
directly on the main screen. Open a link in a new windows? Open the
current page in a new window? Change your font size? Even without
doing a survey, I'm fairly confident that a majority of browser users
don't know how to do those things and may not even be aware that they
are available.

I think changing the font-size and opening-new-windows are two
different things. Even otherwise not "expert" browsing people use
open-in-new-window features often. That's just from my experience
watching family and friends. So if we can't throw around statistics, we
can't agree on any "popular facts" I believe, because it doesn't add
anything valuable to the discussion.
--
Google Blogoscoped
http://blog.outer-court.com