Augmentative authoring- a different look at "graceful degradation" in
Web authoring

The phrase "graceful degradation" is often used to describe
the idea that a Web page that uses special technologies
for presentation enhancements, animation, interactivity, etc.,
should "degrade" to a simpler, yet fully functional page in
circumstancies where the technologies are not applicable.
This document takes a somewhat different view: instead of
considering how to provide "fallbacks" for various advanced
constructs, we consider how to create first a robust document
that works always, then augment it by providing
optional alternatives to the simple constructs.
We'll discuss the different techniques that are needed for different
enhancements.

Web authoring is more than writing structured texts.
There is a wide range of techniques that can be used to enhance
pages with other media and possibilities. Given the fact that the
Web is a many-faced world where very different devices and environments
are used, the key question is how to design pages so that they
always work somehow and appear with the enhancements when
possible.
The key to that is to consider structured text (text with HTML markup
indicating its logical structure) as the immutable core of
a page, as the solid basis upon which various optional
augments can be added. That's my reason for coining
the word augmentative in the Web authoring context.
In a sense, the point here is that Web pages can be more
than text, but they should not be less than text.

Excellent advice on designing Web pages which "degrade gracefully"
can be found in the following documents:

My point of view here is somewhat different, though certainly
compatible with "graceful degradation".
I'll first try to explain the idea with
a small but important example: images.
An image is a graphic enhancement to a textual document, and
in good Web authoring, all image elements have adequate alt
attributes specifying textual replacements for them.
(For specific reasons to this, as well as technical issues on it,
see my Simple guidelines on using ALT texts in
IMG elements.)
But the augmentative authoring approach means that
instead of
first embedding an image and then wondering (if we remember to do that)
what alt attribute to use as a textual surrogate for it,
we first write the text, later build an img
element around it, providing an optional graphic alternative.
Simple as that. There's a very practical benefit: the document will
be functional from the very beginning. Generally, the enhancements
take more work and time to implement, like scanning images,
processing them for better quality, etc. (Admittedly sometimes
it takes more work to write a textual replacement for an image
than to put the image onto a page.)

The essential point is that the page can "work"
in two modes. For images, this simply means that the page can
be viewed so that an image is displayed, or so that some alternative
text is presented (displayed or spoken) instead. For a Java applet,
it could mean that the page can be used so that the user interacts
with an applet that illustrates things dynamically or sees just
a static image that illustrates things to the extent that a static
image can. For frames, this means that a site can be
viewed either using frames or without them, typically using the
equivalent of the content of a navigational frame as a main page.
And so on. As a special case, one of the modes can be "something extra"
like beautiful coloring of a page or checking form data before
submitting it whereas the other alternative is simply lack of the
extra feature. Quite often style sheets and client-side
scripting can be used for such purposes, so that no special
"fallback" is provided, since the feature is strictly optional
as far as basic functionality is considered. (Note that form data
checking must be done server-side in any case, so client-side checks
should be just extra comfort.)

The more enhancements you have, especially when you use
different technologies like frames and JavaScript and
style sheets, the more important it is that you realize that
each enhancement could be separately turned off. Do not assume
any coupling between them unless you absolutely need to.
For example, do not assume that JavaScript is enabled if Java is,
and do not assume that anyone using a frames-enabled browser sees
your images. Do not assume that if someone sees an image on your page
he sees all the other images too. (It's quite possible and often useful
to view a page with automatic image loading turned off and load
images individually.)

This can be characterized by two basic ideas:

duality principle

An enhancement introduces an ingredient which can have
two different manifestations, "simple" and "enhanced",
typically according to the characteristics of the browsing
situation.

orthogonality principle

The enhancements should be orthogonal to each other so that
each of them can individually be "on" or "off" without affecting
the basic functionality or the other enhancements.

The duality principle does not imply that the "enhanced"
alternative is to be used whenever possible.
There can be reasons why users select a "simple" alternative even
if an "enhanced" alternative would work too.
A simple example is turning image autoloading off on a graphic
browser (typically, when using a slow connection).
Similarly, a user might have JavaScript routinely disabled but
enable it when there is a reason.

Should the "simple" version then mention the availability
of the enhanced version? Generally, no. It is reasonable to assume
that the user who sees the simple version either has no choice or
has specifically chosen the simple alternative. In exceptional case,
when there is a special reason why someone might wish to consider
changing his choice temporarily, or even switching to a different
browser if needed, a note could be made. The note should make it
explicit what might be gained by using an enhanced version.
See e.g. remarks on
suggestions
to enable JavaScript.

The following table tries to summarize the usual
methods for implementing the duality for various enhancements.
Note that several possible enhancements are not mentioned at all,
since they need no special treatment; for example, using style sheets
should cause no problems when style sheets are disabled, if the
HTML markup of the document is adequate.
For details on the HTML elements involved, please refer to
HTML 4.0 Reference by
WDG. For features not in
the HTML 4.0 specification, such as embed,
see e.g.
HTML Tag List by Rob Schlüter
(also available as
a version which uses frames)
or Miko O'Sullivan's excellent
HTML Quick List.