Two popular low-overhead browsers
While many surfers must use a text browser because of
physical disability, more folks than you might suspect
eagerly choose to use one, for unrivaled speed
and to subdue visual noise. Statistics on comparative
browser usage aren't very reliable, but they suggest
that use of the lynx
text browser among surfers is just a little less common
than Mac usage among computer users. Dedicated volunteer
programmers keep lynx stable, compliant with current W3C
standards, and available for most platforms.
See for yourself
You'll find that the constraints of the
80xNN screen make lynx neither the lowest
common denominator nor a creaky antique
if you telnet
to a public lynx v2.8.5 installation (fear not;
log in as guest, type k for keyboard help, g = goto url,
and to quit Q). When you open a page, search the word
"print"; if a printer version is available,
it will get right to the point ( / = search and n =
search again). You won't get to experience some lynx
advantages (e.g., the ease with which you can email
a displayed page to yourself or a colleague), but
at least you'll get to sample lynx speed and the Web
the hustlers forgot.
< L Y N X A L E R T: S I D E B A R >
Refusing to submit to MSIE tyranny, I bumbled along for years
with an increasingly obsolete v3.62 Opera win32 browser.
I was insufficiently impressed by improvements in versions
4 to 6 to spring for those releases of the shareware,
and unwilling to tolerate the systemic intrusions
that would drive the banner ads that were the price
of "free" Opera adware. So I welcomed
Opera-copycat firefox and used it, if with
tempered enthusiasm, for a few months.
Then joy! Opera turned pure freeware and to
my delight was vastly improved over all previous
Opera releases I'd tried. I must in fact
contain my enthusiasm lest I sound like some kind
of cultist loon. I can't promise that you'll love
8.5 too, but I do recommend exploring its feature set:
its innovative richness is all the more surprising
given the small size and high speed. Opera's always
been noted for those virtues as well as slavish adherence
to W3C standards, without introducing proprietary
confusion, that makes it consistent with Tim Berners-Lee's
vision of a Web that works for everyone. If you're
mousephobic, the extensive keyboard shortcuts are
demonically unintuitive, but if you master them
anyway you'll almost never have to reach for a
pointing device. I've even become devoted to the
raggedy, unstable Opera 7 that's the most recent release
that works with my iBook's osX v10.1. Anything
that reduces Mac mousing around has to be A Good Thing.
< / S I D E B A R >
Shorn of visual cues, familiar pages will look suddenly
strange in lynx. Contrast some flashy dotcoms with your
favorite newspaper. On the whole, newspapers' centuries
of experience presenting a readable editorial smorgasbord
serve them well on the Web. The most lynx-friendly
maintain text browser editions. At the
nether extreme are commercial suisites
whose misuse of scripting makes them unnavigable by
visitors who turn off graphics and scripting, or who
use a text browser. lynx is somewhat emphasis-challenged
(tagging tips below), but what's wrong with lynx
mostly is sites that nitwit consultants design for clueless
merchants who've experienced the Web only with T1 or
DSL or cable modeum, the fastest hardware, and MSIE,
protected by a firewall, and who assume that's the norm.
To make your site
more accessible--especially if
site might attract disabled visitors--you can
find lynx preview sites, but the text browser makes
such a modest claim on system resources (win9x
lynx occupies a measly 1.56mb of disk space)
lynx in your own system for proofing
win9x lynx). lynx and Opera--given Opera's W3C
compliance--form the perfect preview pair. HTML that
looks good in Opera should work in any W3C-compatible
gui browser. Set Opera preferences->advanced to
use lynx as the "source
viewer" so Ctrl+F3 opens lynx with
the same page displayed. Type \ in lynx to toggle
rendered and tagged view; p[rint] saves to disk in
either form; e opens the page in your editor of choice,
and lynx has other editing features. Alas, although
it uses win9x services, lynx runs in a graceless dos box.
My editor of choice is the dos
text processor xyWrite 3 plus the !xyWise
Web assistant !xyWWWiz. Runner-up:
Pro plus the clipbook that uses the same
strategy as the !xyWWWiz/Windows xyWrite &
(Although the points made by this basic piece on
HTML editors vs the "wysiwyg"
tools that generate all that cruddy tagging
lead to a soft sales pitch, they're no less true.)
The lynx I use to surf and edit online is the one
in my ISP's unix shell. Web text looks comparatively
elegant with my color-configurable telnet client's
oem fonts, and NYTimes-required cookies--the only ones
I accept--are thus confined to my ISP's server, not
my hdd. Online I turn to Opera mostly when a lynx
rendering would be meaningless-- e.g., the !xyWWWiz
html color chart.
Extend your site's reach
4 january 2004
Would you exclude all Mac users from your site?
Although the percentage of text browser users is
small too, the real number is substantial. To that
count, fold in the number of users of any browser that
toggles features like graphics, scripting, and frames.
Tagging pages that are lucid
in all browsers just requires a little attention
to detail. You probably already know that
using img alt= attributes is important.
To dispose first of the worst obstacle to smooth surfing:
What tagging challenge could be more formidable than a tv
schedule grid with linked descriptions of the shows? If
zap2it can manage to present dynamic grids that
choke neither lynx nor Opera with scripting
turned off, can any site with a less inherently demanding
mission justify less dexterous scripting? Only you know what
is appropriate for your <noscript> alternative, but
it's "requires." When some elements of the site
legitimately require scripting for security or whatever,
encourage visitors to return with a script-enabled browser
by keeping the rest of the site freely accessible.
If your pages require
scripts for navigation or access to crucial information,
remember that the Web doesn't want for more courteous rivals
for the attention of visitors your site snubs.
For the most part, lynx reflects layout intent only as
indicated by list and blockquote tags and alignment
attributes. But tables
are valid W3C html tags, and lynx is no reason
to dodge them.
Just be aware of the effect. If you compel a gui browser
to calculate a zillion tables on one wordy page (e.g.,
this site's xyWrite resources page) or even a few verbose
tables, it loads almost as sluggishly as an image-burdened
page. Table tags give grief to software that converts Web
pages to speech. lynx issues depend on the table's purpose.
Does it control layout by positioning sections or does it
chart content that's innately tabular?
Assume lynx won't show tabular-content
tables as spec'd. It seems to be getting
closer to being able to line up columns in
tabular charts, but it's not there yet.
For tabular-content tables to work, each row must fit on
one 80xNN line and apparently columns must be able to be
aligned without overruns--in other words, <td> cells
per <tr> must be relatively short and few. When
it works, it works effortlessly, but a minor edit can
inexplicably collapse the structure. win9x lynx v2.8.3
lines up the "Rigmarole"
"Specs" as a chart; the unix lynx development
v2.8.2 that my ISP in his infinite wisdom downgraded
to, scrambles the same table.
My best advice on this aspect of table tagging
is to search the Web for better advice.
comp.infosystems.www.authoring.html guru Alan J.
Flavell has written a lot on tagging effectively
for all browsers, including a paper on
inherently tabular content.
The good news is that you need do little
or nothing to insure that layout
tables content is lucid in lynx
too--a good thing since without 'em the Web would be
dismal visually. Unless content fits the narrow parameters
just noted, the browser ignores table tags: Text flows
as if the tags weren't there. When a cellular sidebar
(e.g., the Opera note above) disrupts continuity,
inserting a gui-subliminal lynx alert (described below)
wouldn't hurt. But lynx layout-table legibility often
involves nothing more than placing <br> and
<hr> tags judiciously--often before </td>;
just proof it with lynx. The
large issue isn't the way lynx handles layout tables,
it's focus and navigability problems that table
manipulation often induces. You may need to correct
a bigtime design error of omission.
Although lynx responds to hN,
bf, ital, etc tags, type is one font, one size.
Emphasis made obvious
by font specs and table-tagged columns can not be
seen in lynx. While a gui browser
projects what's important at a glance, elements that
table tags bounce to the top of the screen and that type
size and color amplify, in lynx are undifferentiated and
buried many, many 80xNN screens from the top.
When you read your own pages with tags stripped, is
the main content buried far distant from the top?
No, you are not obliged to confine your site
to monotonous inverted-pyramid presentation or to
build a b&w shadow site for text browsers.
You needn't alter your design perceptibly to tell
text pilots explicitly what you signal visually
One prevalent tables-aided strategy divides pages into
columns with the interior
column(s) as the focus, often-copious boilerplate
on the flanks. The layout looks handsome
in gui browsers and if the page is otherwise well made
lynx renders it nicely. But this innocent template
sends the text troops on a frustrating PgDn treasure
hunt through an unpredictable amount of left-column(s)
boilerplate in quest of the booty. If highly motivated,
those who use lynx by choice can study the layout with
a gui browser and sometimes devise a labor-intensive
work-around; surfers who must use lynx lack
even that option.
Ironically, these pages could easily look exactly
as they do now in gui browsers and simultaneously
send the text tribe straight to the good stuff.
What works well in lynx is the kind of page that
the "print this article" convention
produces, and in articles a link at the top of
the page that would jump lynx users to that
option is all that's needed. Index pages that
don't ordinarily offer the option just need
a little more work.
Index pages and some articles at the CNN site
apply a sublimely
inventive example of html juju: The
first element at the top of the page is a gif,
10w X 1h, hspace and vspace and border =0,
alt="Skip to main content," embedded
in a link that points to a name anchor at the
beginning of the main content area. Although
the link works (if you know it's there and thus
can find it), that alt= legend doesn't render
with graphics turned off in my gui browser,
but "Skip to main content" jumps off
the top of the lynx-rendered page. CNN thereby
performs a service of inestimable value to
lynx users at no cost to the page's design.
To study the
tagging, search "ContentArea" links.
<update, 4 january 2004: Since this
graf was written, many other sites have followed
CNN's example--the Seattle Times and (if you
can believe) the White House (yes, that
White House) come to mind, and the invaluable
cursor news blog
promptly added the convenience after a single
email to the editor requesting it, thus saving
lynx users 18 PgDns per visit.>
I consider use of tags that accomplish
what the CNN tags do as important to lucidity
in lynx as the use of alt= img tag attributes.
Here's how some other
publications, without taxing users of gui browsers,
could remove hazards to lynx navigation
by adapting the CNN technique (which well may have
been devised by someone else originally; CNN just
happens to be the only site I know that applies it).
The Washington Post, The New York Times, Salon,
and Arts and Letters Daily do just about everything
else right for accessibility. No scripting that
trips nonscript browsers. No dumb frames. No
imagemaps. Relatively careful <img> tag
alt= values. ... Except, to avoid endless random
PdDns to get to new content, text trekkers must
identify, type, and repeatedly search various
strings. The tagging below already is in use except
for proposed tags, in contrasting type, that would
express text browser users to a page's nittygritty.
For neatness' sake you could make a 1-pixel
"no.jpg" to satisfy some img tags
here, but actually the jpg needn't even exist.
Washington Post, a Web pioneer, has a fine
site if not much in the way of profits to show
for it. Good as the site is, visitors who use
lynx need a little more help than the Post offers.
The Post requires them to search one string to
bypass boilerplate on index pages, a different
string to get to the beginning of an article--or
to PgDn repeatedly. On both index and articles
pages, the same link would work in the same place
under the body tag at the top of the noscript link list:
<BODY LINK="#333399" VLINK="#333366" ALINK="#CC0000" BGCOLOR="#FFFFFF" TOPMARGIN="0" MARGINWIDTH="10" MARGINHEIGHT="0">
<a href="#main"><font size="-6" color="#CCCCCC">
<img alt="<skip to main content>" src="no.jpg" align="right" width="1" height="1" hspace="0" vspace="0" border="0"></a></font>
<font size="-2" face="verdana, ms sans serif, arial">
<b>News Home Page</b></font></a>
On index pages that link would point to
an anchor just before the date comment
at the beginning of articles listings--
<!-- start middle 468 -->
--and in articles would point to the
<!-- print/body -->
<!-- date -->
<FONT FACE="Arial,Helvetica" COLOR="#333333" SIZE="-1"><b>Wednesday, August 22, 2001</b></FONT><BR>
<TR><TD WIDTH="6" HEIGHT="16">
<SPACER TYPE="block" WIDTH="6" HEIGHT="16"></TD>
<TD WIDTH="34" ALIGN="right" VALIGN="bottom">
<IMG SRC= "http://a188.g.akamaitech.net/f/188/920/1h/www.washingtonpost.com/ wp-srv/images/icon_print.gif"
WIDTH="24" HEIGHT="11" BORDER="0" HSPACE="5" VSPACE="0"></TD>
<TD ALIGN="left" WIDTH="178" VALIGN="bottom">
<FONT SIZE="-2" FACE="verdana, arial" color="#666666">
<TD WIDTH="8" HEIGHT="1">
<SPACER TYPE="block" WIDTH="8" HEIGHT="1"></TD>
The New York
Times's most recent major design changes turned
the site, previously cited here for lynx-friendliness,
distinctly lynx-antagonistic. Editorial content
on headlines-only index pages and in articles used
to start at the top. Now, in both, searching the
word "e-mail"--repeatedly in articles--gets
you crudely somewhere near content. The Times could
remedy the problem so easily, with tagging
that wouldn't alter the appearance in a gui browser:
<body marginheight="5" marginwidth="0" leftmargin="0" topmargin="5" bgcolor="#ffffff" link="#000066" alink="#990000" vlink="#444464">
<NYT_HEADER version="1.0" type="main">
<table width="768" border="0" cellpadding="0" cellspacing="0">
<tr><td colspan="6" width="768" bgcolor="#ffffff" height="5">
<a href="#main"><img alt="<skip to main content>" src="http://graphics.nytimes.com/images/misc/spacer.gif" width="768" height="5" border="0"/></a>
The index pages target tag should follow the search
form that names names, making the Times site feel
as suffocating now as AOL:
<table border="0" width="469" cellspacing="0" cellpadding="0" bgcolor="#ffffff">
<tr><td width="274" valign="top">
<img src= "http://graphics.nytimes.com/images/misc/spacer.gif" width="274" height="1" border="0"/><br>
<font face="Times,Times New Roman,Serif" color="#000066" size="+1"><strong>
In articles, the target anchor should immediately
precede the print-article option--
<A HREF="http://ea.nytimes.com/cgi-bin/email?REFURI= http://www.nytimes.com/2001/08/21/politics/21ECON.html">
<a href="http://ea.nytimes.com/cgi-bin/email?REFURI= http://www.nytimes.com/2001/08/21/politics/21ECON.html">
<img src= "http://graphics.nytimes.com/images/article/functions/ emailArticle2.gif" width="147" align="top" height="19" border="0" alt="E-Mail This Article"/>
<img src= "http://graphics.nytimes.com/images/article/functions/ printArticle2.gif" width="131" height="19" border="0" align="top" alt="Printer-Friendly Format"/></a>
--but since The Times apparently wants you to know
it knows who you are and where you live, in both
cases it's probably more realistic (if that's the
word) to request that the anchor be placed at the
beginning of the search option, although that then
requires eight ill-will-inducing punches of the
Tab key to get to the print-article option:
<table width="669" border="0" cellpadding="0" cellspacing="0" bgcolor="#CCCCCC">
<form action= "http://archives.nytimes.com/plweb-cgi/search.cgi" method="post">
<input type="hidden" name="fields" value="ALL">
<input type="hidden" name="section" value="ALL">
<tr><td width="669" height="3" colspan="9">
needs all the help it can get these days, here's
mine to enhance the invaluable online newspaper's
attractiveness to users of text browsers. To evade
countless PgDns, text trekkers must type and search
the day of the week to get to the toc for new
original articles or search "wires"
for wire copy, and in articles must type, search,
and Enter "print" to read the piece whole
and less boilerplate. How much better if at the
top of index pages Salon added tagging like this
that would be all but invisible in gui browsers:
<body bgcolor="#ffffff" text="#000000" link="#cc0000" alink="#666666" vlink="#666666">
<img alt="<skip to main content>" src="no.jpg" align="right" width="1" height="1" hspace="0" vspace="0" border="0"></a>
--with a target tag just before the page's main
content (remember, lynx ignores layout table tagging):
<table border="0" cellpadding="0" cellspacing="0">
<!-- <col_3/> -->
<!-- col_3_top.mc -->
A different linkage is wanting in Salon articles.
The target print-story option (print piece to
screen less boilerplate on one page--"view
as one page") might take this form:
<body bgcolor="#ffffff" text="#000000" link="#cc0000" alink="#666666" vlink="#666666">
<!-- 66 72 79 90 91 92 93 125 163 238 244 405 455 -- 45 -->
<img alt="<Print Story>" src="no.jpg" align="right" width="1" height="1" hspace="0" vspace="0" border="0"></a>
<!-- ads table -->
With its faith in the power of language
over visual embellishment to stimulate interest
and dozens of leads linked to some of the most
thought-provoking text on the Web,
& Letters Daily should have a
symbiotic affinity with a text browser. Nonetheless,
the site is all but impenetrable with lynx unless
the user analyzes it first with a gui browser, notes
the subheds of the three main sections (each is
distinct at the top of the gui page), and types
and searches each subhed each visit. Oy!
ALD asks readers to tell students and mailing list
fellow subscribers about the site and to "make
us your home page." lynx attracts the kind
of users who'd be inclined to do those very things
unprompted if ALD would transform part of the
folio into a discreet shortcut to the first
editorial section, and lead from that link to
new links at the beginning of the other two main
sections. This scheme gets the user right to the
first section, then cycles through the three:
<hr size="1" color="#000000" noshade>
ALD target tag #1 and navigation aid #2:
<center><table width="95%" cellpadding="0" cellspacing="0" border="0"><tr>
<td><font size="2"><a href="homepage.htm "style="text-decoration:none">MAKE US YOUR HOMEPAGE</a></font></td>
<td align="center"><center><font color="#ff0000" size="2"><b>
Weekend Edition</b>, <b>August 18-19</b>,<b> 2001</b></font> </center></td>
<td align="right"><font size="2">VERITAS ODIT MORAS</font></td>
<!-- hr size="1" color="#000000" noshade -->
<a href="#col1"><img alt="<skip to Articles of Note>" src="no.jpg" width="97%" height="1" border="0"/></a>
ALD target tag #2 and navigation aid #3:
<font size="-6" color="#fdf7f1">
<img alt="<skip to New Books>" src="no.jpg" width="1" height="1" vspace="0" hspace="0" border="0" align="right"/></font></a>
<!-- GUTTER 1 END LINK COLUMN -->
<hr size="1" width="80%" color="#000000" noshade></font>
ALD target tag #3 and navigation aid #4,
which cycles back to target tag #1:
<a href="#col3"><font size="-6" color="#fdf7f1">
<img alt="<skip to Essays and Opinions>" src="no.jpg" width="1" height="1" vspace="0" hspace="0" border="0" align="right"/></font></a>
<!-- GUTTER - END CONTENT COLUMN 1 -->
<hr size="1" width="80%" color="#000000" noshade></font>
<a href="#col1"><font size="-6" color="#fdf7f1">
<img alt="<skip to Articles of Note>" src="no.jpg" width="1" height="1" vspace="0" hspace="0" border="0" align="right"/></font></a>
<!-- GUTTER - END COLUMN 2 -->
Whatever, do what somebody at CNN obviously did:
Proof your pages in lynx to
see what tables are doing--or not doing--that
sabotages your message, and what you can do to
clarify it. Granted, the goal of increased traffic
at .com sites is higher numbers to present to ad
agencies that probably write off visits with text
browsers but, if lynx users are going to visit
the site anyway, why not make life easier for them
since doing so takes so little effort? Disabled
lynx users have no choice, and others will return
with a gui browser if content justifies it.
Till now, this page has proposed a different
gui-subliminal remedy, as effective but less
elegant than CNN's, and I salute CNN's superior
solution. Nonetheless, the old device still is
useful for sending
any kind of message--not just navigational help--to
text browsers only. This page contains
a gui-subliminal clarification where table tagging
confuses lynx text flow (a sidebar is labeled as
such). The technique: Tag the lynx alert the same
<font color="#??????"> as the
background color, in the smallest possible size
(a series of <small>s seems to go smaller
in Opera than <font size="-N">
achieves), where possible in blank space. The msg
will be invisible to gui browsers and in lynx will
look like any other type. Using the device along
with the CNN solution (as the proposed ALD tagging
above does) isn't a bad idea. Applying a variation
of the old technique, since lynx can't render the
html-generated square bullets that break sections
on the gui screen here, the tagging that creates
them renders a # hash in lynx that gui browsers
don't ordinarily display:
Surfers so universally despise
it's surprising these tags still are in use. If you insist on
practicing this perversion, recent lynx releases accommodate
you. Absent a graceful <noframes> alternative, a list
greets the visitor, who must guess which file name--left.html,
nav.html, body.html, etc--looks most promising. Yech.
not widely known for Web sophistication, offers the
most considerate solution I've ever encountered:
If a Fry's is ever near, count on seeing me.
Meanwhile, I'll be watching Egghead.com to see
if the Fry's Electronics' acquisition becomes
- FRAME: navigation
- FRAME: logo
- FRAME: main
- Welcome To Fry's Electronics home page.
We apologize to all of our Lynx users for our framed
format. [...] To navigate the site please select the
"navigation" frame. Please select the
"main" frame for the meat of the site.
We thank you for stopping at the home of fast,
friendly, courteous service and we hope we
will see you in a Fry's Electronics near you.
tag alt= attributes are vital to lucidity
in both lynx and gui browsers with graphics turned off.
When you omit the attribute, lynx substitutes one of the
bracketed terms below, and pages that in their entirety
look like that incomprehensible mess are common. They're
almost as ugly in gui browsers with graphics turned off.
- Never ever write an img src= attribute till
you've written an alt= attribute.
- If the image moves the story forward,
as the alt= value
simulate typographically what a gui browser will show.
Don't describe the graphic.
Simulate it typographically--if the graphic is narrative.
- When the image contains text, repeat the text as
the alt= value.
- If the img is a graphical bullet, make the value an
asterisk--alt="*", not alt="bullet" (etc).
- But if the image is purely ornamental (e.g.,
the boat photo on this site's home page), save your time
and the visitor's: Place nothing between alt=""
- A <br> should follow the <img> tag.
If that disrupts text display, embrace alt= content
with < and > (< and >) entities and
the <img> tag with <b> or <i> tags:
<b><img alt="< new! >" src="new.jpg"
width="54" height="58" vspace="8" hspace="18"