skip to low-tech html tagging tips || <home> | <xyWrite resources> | <!xyWWWiz>

the alternatives

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 Opera 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 the 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) consider installing lynx in your own system for proofing (download 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: NoteTab Pro plus the clipbook that uses the same strategy as the !xyWWWiz/Windows xyWrite & NotaBene !BetterThanAverageTaggingTool. (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 (NetTerm) 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

new! 15 january 2001
last modified
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 an inyerface "This site requires Javascript" message is worse than none. The menace isn't Javascript, 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 conventional 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 tagging 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 to mouseketeers.

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.

The 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:
<SCRIPT LANGUAGE="javascript" SRC=" wp-srv/javascript/channelnav/channelnav.js"></SCRIPT>
<tr><td bgcolor="#CCCCCC">
<a href="#main"><font size="-6" color="#CCCCCC">
<img alt="&lt;skip to main content&gt;" src="no.jpg" align="right" width="1" height="1" hspace="0" vspace="0" border="0"></a></font> </td></tr>

<tr><td bgcolor="#CCCCCC">
<A href="">
<font size="-2" face="verdana, ms sans serif, arial">
&nbsp;<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 -->
<TD WIDTH="468">
<!-- print/body -->
<a name="main"></a>
<!-- date -->
<br clear='all'>
<FONT FACE="Arial,Helvetica" COLOR="#333333" SIZE="-1"><b>Wednesday, August 22, 2001</b></FONT><BR>
<HR SIZE="1">
--and in articles would point to the print-article option:
<TR><TD WIDTH="6" HEIGHT="16">
<SPACER TYPE="block" WIDTH="6" HEIGHT="16"></TD>
<TD WIDTH="34" ALIGN="right" VALIGN="bottom">
<IMG SRC= " wp-srv/images/icon_print.gif" WIDTH="24" HEIGHT="11" BORDER="0" HSPACE="5" VSPACE="0"></TD>
<TD ALIGN="left" WIDTH="178" VALIGN="bottom">
<a name="main"></a>
<FONT SIZE="-2" FACE="verdana, arial" color="#666666">
<A HREF="/ac2/wp-dyn/A42020-2001Aug21?language=printer">
<B>Printer-Friendly Version</B></A><BR></FONT></TD>
<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="&lt;skip to main content&gt;" src="" 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">
<a name="main"></a>
<img src= "" 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--
<td width="147">
<A HREF="">
<a href="">
<img src= " emailArticle2.gif" width="147" align="top" height="19" border="0" alt="E-Mail This Article"/>
</a> </a></td><!---->
<td width="131">
<a name="main"></a>
<A HREF="/2001/08/21/politics/21ECON.html?pagewanted=print">
<img src= " 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">
<a name="main"></a>
<form action= "" method="post">
<input type="hidden" name="fields" value="ALL">
<input type="hidden" name="section" value="ALL">
<tr><td width="669" height="3" colspan="9">

Since Salon 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">
<a href="#main">
<img alt="&lt;skip to main content&gt;" 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):
<a name="main"></a>
<table border="0" cellpadding="0" cellspacing="0">
<!-- <col_3/> -->
<!-- -->
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 -->
<div align="center">

<a href="print.html">
<img alt="&lt;Print Story&gt;" 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, Arts & 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>

<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="&lt;skip to Articles of Note&gt;" src="no.jpg" width="97%" height="1" border="0"/></a>
ALD target tag #1 and navigation aid #2:
<a name="col1"></a>
<a href="#col2">
<font size="-6" color="#fdf7f1">
<img alt="&lt;skip to New Books&gt;" src="no.jpg" width="1" height="1" vspace="0" hspace="0" border="0" align="right"/></font></a>

ALD target tag #2 and navigation aid #3:
<hr size="1" width="80%" color="#000000" noshade></font>
<a name="col2"></a>
<a href="#col3"><font size="-6" color="#fdf7f1">
<img alt="&lt;skip to Essays and Opinions&gt;" src="no.jpg" width="1" height="1" vspace="0" hspace="0" border="0" align="right"/></font></a>

ALD target tag #3 and navigation aid #4, which cycles back to target tag #1:
<hr size="1" width="80%" color="#000000" noshade></font>
<a name="col3"></a>
<a href="#col1"><font size="-6" color="#fdf7f1">
<img alt="&lt;skip to Articles of Note&gt;" 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 frames 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. Fry's Electronics, not widely known for Web sophistication, offers the most considerate solution I've ever encountered:

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.

If a Fry's is ever near, count on seeing me. Meanwhile, I'll be watching to see if the Fry's Electronics' acquisition becomes as lynx-friendly.


Global img 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.
    • 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).
    Don't describe the graphic. Simulate it typographically--if the graphic is narrative.
  • 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="" quotes.
  • A <br> should follow the <img> tag. If that disrupts text display, embrace alt= content with < and > (&lt; and &gt;) entities and the <img> tag with <b> or <i> tags:
    <b><img alt="&lt; new! &gt;" src="new.jpg" width="54" height="58" vspace="8" hspace="18" border="0" align="left"></b>

If you install lynx you'll see why a <br> usually should follow the img tag and why, when you have an img that's a decorative line, if it serves no practical purpose you needn't be shy about using alt="" and why if it separates sections you should use alt="------------------", not alt="line" (which I actually saw recently). Consider the perception.

      [LINK]       [LINK]      [LINK]
[IMAGE]    [IMAGE]   [IMAGE]     [IMAGE]


Imagemaps with no textual alternative are the work of the devil.


And in conclusion ... here's a tiny, truly ingenious Web util that coulda saved me a massive amount of spam grief if I'd known about it at the right time: Entity-encodes an email address for use in your Web pages in a way that thwarts spiders building spam mailing lists.

tables -> innately tabular | layout | gui-subliminal tags: why? how? | case studies > news | Salon | Arts & Letters Daily || frames || img || scripts ||

crib sheet  

Tag your pages so they work in both gui and text browsers: a summary of tips
  • Never write an img src= attribute till you've written an alt= attribute.
    • If the image is narrative, as the alt= value simulate typographically--don't describe--what a gui browser will show.
    • If the image is ornamental, use an empty alt="".
    • A <br> usually should follow the img tag.
  • Layout tables
    • Make sure breaks occur where you want them to.
      Use <br> and <hr> tags judiciously--often before </td>.
    • If a lot of secondary content precedes a given page's main section(s), consider using in-page navigational links: Mark the beginning of dominant sections with <a name="N"> tags and at top of page embed in <a href="#N"> links a real or dummy <img> tag with alt= content pointing to it. You also can hide lynx-directed msgs in smallest-font, gui-invisible (same color as background) lynx alerts.
  • When content is inherently tabular, designing a table that will succeed simultaneously in gui and text browsers at best is tricky. Sometimes the only solution is a linked shadow table <pre>-tagged for lynx. Look for expert advice on this aspect of table tagging elsewhere on the Web.
  • If you tag frames, write generous <noframes> alternatives.
  • Install <1.6mb lynx in your own system for proofing if for no other purpose.
  • Feeling cybersuisital? Yes? Then use scripting to program your site to be unnavigable with scripting turned off or use <noscript> with an insulting "This page requires blahblahscript" message.

adpFisher nyc 7 March 2006
low-tech html tagging tips | <top> || <home> | <xyWrite resources> | <!xyWWWiz>