Why is this site a flop?

[Murray R. Van Luyn]

Hi,

Since I have made changes to my website it's been a complete flop. According
to the logs, as soon as visitors have downloaded the index page they are
off. I can't figure out why?

http://www.review-a-gadget.com/

Is there anything obvious that I am missing? Are there problems with some
browsers? Please let me know if you notice anything.

Thanks very much for any help you might be able to offer.

Regards,
Murray R. Van Luyn.
--
http://www.review-a-gadget.com/
http://members.iinet.net.au/~vanluynm/

[Murray R. Van Luyn]

Hi Eric,

"Eric Lindsay" <NO*************@ericlindsay.comwrote in message
news:NO***********************************@freenew s.iinet.net.au...

How about changing your title to:

Toys for young boys - review-a-gadget.com

You still don't have a h1 header to help search engines decide what your
site is about. Mention Airsoft toys.

Thanks for that Eric. Yes I'm still trying to decide what sort of blurb I
should use on the opening page. You're right, it should give a much better
impression of what the site is about ie. toys. It had slipped my mind that
it would be very important to use a H1 tag in this blurb for the benefit of
search engines. Thanks for the reminder.

Your left hand side menu doesn't work (actually doesn't even appear) in
any browser in which Javascript has been disabled. Some businesses block
javascript. Some people recommended switching it off when browsing
unknown sites. Some people switch it off to block annoying advertising.
Also, I am not sure search bots bother to follow Javascript only links.

Yes, despite the groovy drop shadow and transition effects, there were a lot
of problems with the JavaScript menu. It didn't seem to position correctly
for the almost 30% of websurfers that I believe now use FireFox, and was
never going to appear for surfers with JavaScript turned off.

Never mind. The JavaScript menu has been replaced with a pure CSS version
adapted from Stu Nicholls' one at CSS Play.
http://www.cssplay.co.uk/menus/flyoutt.html Thank you Stu. This was the best
behaved one I could find, and it doesn't use any JavaScript as pretty much
all the others seemed to.

Except for having yet to come up with an interesting opening blurb,
hopefully that's the majority of reasons why visitor's weren't getting past
the first page dealt with.

Now I just have to work out how to get relisted with Google, who seem to
have nailed me for one of my PageRank tricks overnight. It's okay, I
expected that. Gee, it all worked just fine with MSN.

Regards,
Murray R. Van Luyn.
--
http://www.review-a-gadget.com/
http://members.iinet.net.au/~vanluynm/

[Murray R. Van Luyn]

Hi Sherm,

"Sherm Pendley" <sp******@dot-app.orgwrote in message
news:m2************@Sherm-Pendleys-Computer.local...

Quite right, but the "site map" links at the bottom of the page lead to
the
same pages. IMNSHO, this is a good example of using JavaScript correctly,
as an enhancement rather than as a requirement.

I would actually take it one step further, and in the JavaScript code add
a CSS attribute "display:none" to the div containing the site map. That
would
leave the site map links visible for those who need them, while getting
rid
of some unnecessary visual clutter for those who can use the menu.

That's interesting. Gee, all the fun tricks you can do with dynamic HTML.
I'm really going to enjoy learning more about and using CSS, maybe with a
little JavaScript thrown in when appropriate. I'm definitely looking forward
to restyling those terrible tables that I have hidden at the bottom of most
pages.

Regards,
Murray R. Van Luyn.
--
http://www.review-a-gadget.com/
http://members.iinet.net.au/~vanluynm/

[Eric Lindsay]

In article <m2************@Sherm-Pendleys-Computer.local>,
Sherm Pendley <sp******@dot-app.orgwrote:

Eric Lindsay <NO*************@ericlindsay.comwrites:

Your left hand side menu doesn't work (actually doesn't even appear) in
any browser in which Javascript has been disabled. Some businesses block
javascript. Some people recommended switching it off when browsing
unknown sites. Some people switch it off to block annoying advertising.
Also, I am not sure search bots bother to follow Javascript only links.

Quite right, but the "site map" links at the bottom of the page lead to the
same pages. IMNSHO, this is a good example of using JavaScript correctly,
as an enhancement rather than as a requirement.

However the sitemap items are below the fold. Browsing without
javascript, a person might enter the page, see no obvious navigation
near the top, and exit the page. Your next paragraph does cover that
situation, and suggests a solution.

Is the Javascript really being used correctly, as an enhancement? Maybe
I missed it, but I didn't see any rollover that couldn't be done with
CSS just as easily.

Now if it had been something like hiding part of contributed content
(like showing the first few lines of a review, and expanding to the full
review if clicked) then I could see arguing the javascript was an
enhancement.

>
I would actually take it one step further, and in the JavaScript code add
a CSS attribute "display:none" to the div containing the site map. That would
leave the site map links visible for those who need them, while getting rid
of some unnecessary visual clutter for those who can use the menu.

sherm--

That does seem like a reasonable idea. However I wonder whether search
engines are detecting use of display none, and penalising hiding of
multiple links? I don't think so, but they keep tuning their algorithms.

--
http://www.ericlindsay.com

[Sherm Pendley]

Eric Lindsay <NO*************@ericlindsay.comwrites:

Is the Javascript really being used correctly, as an enhancement? Maybe
I missed it, but I didn't see any rollover that couldn't be done with
CSS just as easily.

True, but I think *some* credit is still due to the OP. Even if his effort
falls somewhat short of the ideal, the fact remains that he *did* at least
provide support for non-JS users. Far too many web authors don't.

>I would actually take it one step further, and in the JavaScript code add
a CSS attribute "display:none" to the div containing the site map. That would
leave the site map links visible for those who need them, while getting rid
of some unnecessary visual clutter for those who can use the menu.

That does seem like a reasonable idea. However I wonder whether search
engines are detecting use of display none, and penalising hiding of
multiple links? I don't think so, but they keep tuning their algorithms.

It depends; if you're using JavaScript for the menu, then that same JavaScript
could also apply the display:none. Search engines, not being JS-aware (that I
know of) would never know that display:none is being used. (That would have
the disadvantage of the links being visible briefly, then disappearing when
the CSS is applied.)

On the other hand, a pure CSS menu could be built using the same link elements
that would appear on the bottom of the page in a non-CSS browser. That would,
I agree, be a better solution - you wouldn't have to worry about hiding one or
the other.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Martin Clark]

Eric Lindsay wrote...

>That does seem like a reasonable idea. However I wonder whether search
engines are detecting use of display none, and penalising hiding of
multiple links? I don't think so, but they keep tuning their algorithms.

That's a worrying thought. I have been using display:none at the top of
each page for links to Access Keys. Is there another way not to display
these?
--
Martin Clark

[K A Nuttall]

Martin Clark wrote:

That's a worrying thought. I have been using display:none at the
top of each page for links to Access Keys. Is there another way
not to display these?

See other comments in this sub-thread.

display:none can be set using javascript, like this:
document.getElementById('hidemediv').style.display = "none"

--
K A Nuttall
www.yammer.co.uk
Re-type the e-mail address how it sounds, remove .invalid

[Toby Inkster]

axlq wrote:

And one for Opera. It's hard to tell the proportion of Opera users,
because that browser spoofs the IE User-Agent identification string.

Not (by default) since 8.0, when it started identifying as

"Opera/x.y (platform details)"

where "x.y" is the version number and "platform details" contains OS and
interface language details.

I've noticed minor differences in the way Opera displays things,
plus one quirk in failing to set proper default coordinates for
hidden block elements.

For the most part, Firefox and Opera can make do with the exact same
stylesheets. I develop mostly in Opera, and then tweak things to get them
working in Gecko and Opera afterwards.

To get things working in Gecko-based browsers, it's usually just a case of
adding a few *extra* rules in places where I'd assumed partcular browser
defaults. (e.g. Opera, by default has padding, but no margin on the BODY
element. Gecko has it the other way around. By explicitly setting both
padding and margin, you can achieve the same effect in both browsers.)

There are occasionally some parts of CSS 2.1 or CSS 3 that Firefox can't
be made to understand at all, but in these cases, it's generally best to
go back to the drawing board and find a way of achieving the same effect
without using those particular CSS features, because if Firefox can't
understand them, then there's no hope in hell of getting them to work in
IE.

Off the top of my head, I can only recall one time in the past 2-3 years
when I specifically needed to set a particular style differently in Gecko
and Opera. In this case I used an HTTP 'Link' header to feed in an
additional style sheet using a 'data:' URL which Gecko is the only browser
savvy enough to understand. (Opera understands 'data:' URLs, but for some
reason has never implemented support for the 'Link' header.)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Toby Inkster]

Martin Clark wrote:

That's a worrying thought. I have been using display:none at the top of
each page for links to Access Keys. Is there another way not to display
these?

Better idea would be to use Javascript to shift them off the screen
9999px to the left.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Martin Clark]

Toby Inkster wrote...

>Martin Clark wrote:

>That's a worrying thought. I have been using display:none at the top of
each page for links to Access Keys. Is there another way not to display
these?

Better idea would be to use Javascript to shift them off the screen
9999px to the left.

Could not CSS be used to do that?
--
Martin Clark

[Murray R. Van Luyn]

Hi Group,

Somewhere in this thread someone very kindly pointed out that I should be
using dashes instead of underscores for filenames. ie
Airsoft-Gun-Reviews.php instead of Airsoft_Gun_Reviews.php.

I can't find the original message, forgot to ask the original contributor
the advantages of doing that, and now I'm worried.

Anyone know why I might want to adopt such a strategy?

Regards,
Murray R. Van Luyn.
--
http://www.review-a-gadget.com/
http://members.iinet.net.au/~vanluynm/

ps. This is just about the nicest, most helpful group I've ever spoken to.
Good on you people.

[Sherm Pendley]

"Murray R. Van Luyn" <va******@NOSPAM.iinet.net.auwrites:

Somewhere in this thread someone very kindly pointed out that I should be
using dashes instead of underscores for filenames. ie
Airsoft-Gun-Reviews.php instead of Airsoft_Gun_Reviews.php.

I can't find the original message, forgot to ask the original contributor
the advantages of doing that, and now I'm worried.

Anyone know why I might want to adopt such a strategy?

No technical reason I can think of. It's a little bit easier to type a dash
on a US keyboard - no shift key required - but that's hardly worth renaming
your files over.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Murray R. Van Luyn]

Hi Sherm,

"Sherm Pendley" <sp******@dot-app.orgwrote in message
news:m2************@Sherm-Pendleys-Computer.local...

"Murray R. Van Luyn" <va******@NOSPAM.iinet.net.auwrites:

>Somewhere in this thread someone very kindly pointed out that I should be
using dashes instead of underscores for filenames. ie
Airsoft-Gun-Reviews.php instead of Airsoft_Gun_Reviews.php.

No technical reason I can think of. It's a little bit easier to type a
dash
on a US keyboard - no shift key required - but that's hardly worth
renaming
your files over.

Ah, thank you Sherm. I was worried it was going to have something to do with
the way search engines list sites. I think filenames come into it, but
wasn't sure if interstitial characters were important. I seem to recall
reading something about spaces being the same as dashes and underscore
characters, but I'm not even sure that applied to search engines. I'm
terribly confused, but won't worry too much about that one.

Thanks again.

Regards,
Murray R. Van Luyn.
--
http://www.review-a-gadget.com/
http://members.iinet.net.au/~vanluynm/

[Rik]

Murray R. Van Luyn wrote:

Hi Sherm,

"Sherm Pendley" <sp******@dot-app.orgwrote in message
news:m2************@Sherm-Pendleys-Computer.local...

>"Murray R. Van Luyn" <va******@NOSPAM.iinet.net.auwrites:

>>Somewhere in this thread someone very kindly pointed out that I
should be using dashes instead of underscores for filenames. ie
Airsoft-Gun-Reviews.php instead of Airsoft_Gun_Reviews.php.

>No technical reason I can think of. It's a little bit easier to type
a dash
on a US keyboard - no shift key required - but that's hardly worth
renaming
your files over.

Ah, thank you Sherm. I was worried it was going to have something to
do with the way search engines list sites. I think filenames come
into it, but wasn't sure if interstitial characters were important. I
seem to recall reading something about spaces being the same as
dashes and underscore characters, but I'm not even sure that applied
to search engines. I'm terribly confused, but won't worry too much
about that one.

The main reason for using dashes instead of underscores is that the
underscores tend to get 'lost' if the link is underlined. Not a real
problem if the links are only on the net, if you use printed media with
urls however, it may be well worth it.
--
Rik Wasmus

[Toby Inkster]

Murray R. Van Luyn wrote:

Airsoft-Gun-Reviews.php instead of Airsoft_Gun_Reviews.php.
Anyone know why I might want to adopt such a strategy?

There is some evidence that dashes in URLs get treated as seperator
characters by Google when it's extracting keywords from your URL, but
underscores get treated as word characters. So "Airsoft-Gun-Reviews.php"
will show up in searches for "Airsoft" or "Gun" or "Reviews" or some
combination of those, whereas "Airsoft_Gun_Reviews.php" will only show up
if someone actually searches for "Airsoft_Gun_Reviews".

Also, spaces are more legible when your URL is printed out, as URLs are
often (even on paper) printed underlined, so underscores can go unnoticed.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Toby Inkster]

Martin Clark wrote:

Toby Inkster wrote...

>Better idea would be to use Javascript to shift them off the screen
9999px to the left.

Could not CSS be used to do that?

Aren't we talking about some sitemap links that are only important when
the site's JS-based menu fails to load? If so, then using JS to hide the
sitemap links will be a lot more fruitful than using CSS.

If we're just talking about any old links, then CSS will be more reliable
at hiding links than Javascript.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Martin Clark]

Toby Inkster wrote...

>Martin Clark wrote:

>Toby Inkster wrote...

>>Better idea would be to use Javascript to shift them off the screen
9999px to the left.

Could not CSS be used to do that?

Aren't we talking about some sitemap links that are only important when
the site's JS-based menu fails to load? If so, then using JS to hide the
sitemap links will be a lot more fruitful than using CSS.

If we're just talking about any old links, then CSS will be more reliable
at hiding links than Javascript.

I was talking about access key links, such as:

<p class="skiplink">[<a href="index.htm" accesskey="1">Home
Page</a>]</p>
<p class="skiplink">[<a href="#startcontent" accesskey="2">Skip to
content</a>]</p>

with the CSS: .skiplink {display:none}

These don't need to be visible to the normal visitor but can be helpful
to those using audio browsers.

Would Google penalise a site for using display:none in this way?

Is there a better way to do this?
--
Martin Clark

[Chris Morris]

Martin Clark <ma****@spl.atwrites:

I was talking about access key links, such as:

<p class="skiplink">[<a href="index.htm" accesskey="1">Home
Page</a>]</p>
<p class="skiplink">[<a href="#startcontent" accesskey="2">Skip to
content</a>]</p>

This looks more like a list than a set of paragraphs. Why the '[' and
']' around the links?

with the CSS: .skiplink {display:none}

These don't need to be visible to the normal visitor but can be helpful
to those using audio browsers.

Actually, access keys are so badly implemented they're often rather
unhelpful to people using audio browsers. Dropping the access keys
entirely might be best.

1) In some browsers, they override built-in browser shortcut
keys. Fortunately, the audio browser that used Alt+1 for a very
important function wasn't one of them. Still, they can be a real
accessibility hassle for some users. Numeric keys *reduce* the
chance of this, but don't eliminate it.

In other browsers, the built-in shortcut correctly overrides the
access key, which means any instructions you give to draw attention
to the keys don't work [1]...

It's also not necessarily the browser that they conflict with -
Alt+1-6 on my computer switch between virtual desktops and never
*reach* the browser!

2) Browsers don't generally *tell* users about available access keys
on a page, so the only way someone will discover them is when a key
combination does something unexpected (or you could use one of the
many various ways sites use to tell visitors about the keys, but
that's somewhat unreliable - it becomes yet another site-specific
navigation method).

The idea was pretty good, but since Internet Explorer and the
Mozilla-based browsers managed to comprehensively mess up the
implementation, and Opera avoided that (by having an access key
activation key that couldn't conflict with any browser shortcuts) but
still doesn't have a great way of dealing with them (because of
problem 2), they're sadly unusable on the web.

If you want to provide quick access to important links, use <link-
the browsers that support it do so in a harmless and consistent way,
tell the user about available links, there's actually a reasonable
standard for some of the common link names, and you aren't limited to
that small subset of keys you're sure no-one else is using.

The one place accesskeys might still have a use is for internal web
applications where you know what keys the browser won't use (and/or
all your users don't mind having their shortcuts taken over).

Would Google penalise a site for using display:none in this way?

Google doesn't currently read external CSS files, so no.

[1] And then, "Alt+X on Windows, Ctrl+X on Mac, unless you're using
Opera when it's something else again, etc."

--
Chris

[Martin Clark]

Chris Morris wrote...

>Martin Clark <ma****@spl.atwrites:

>I was talking about access key links, such as:

<p class="skiplink">[<a href="index.htm" accesskey="1">Home
Page</a>]</p>
<p class="skiplink">[<a href="#startcontent" accesskey="2">Skip to
content</a>]</p>

This looks more like a list than a set of paragraphs. Why the '[' and
']' around the links?

I didn't ask for a critique. I plucked that out as an example of what I
was asking about. IIRC the '[' and ']' were added after Wave Web
Accessibility Tool (http://dev.wave.webaim.org/index.jsp) complained
about adjacent links with nothing separating them. Anyway, it hardly
matters if the links are not shown.

>with the CSS: .skiplink {display:none}

These don't need to be visible to the normal visitor but can be helpful
to those using audio browsers.

Actually, access keys are so badly implemented they're often rather
unhelpful to people using audio browsers.

[snip interesting comments on Access keys]

However, there is an expectation (requirement?) now in the UK for the
web sites of organisations to address issues of accessibility, and in
practice this usually includes the use of Access keys.

>

>Would Google penalise a site for using display:none in this way?

Google doesn't currently read external CSS files, so no.

That's a relief. I'll stop worrying about it for now.

Incidentally, I came across a local council website
(http://www.portsmouth.gov.uk) that had a rather different way of making
the links invisible:
.Invisible { line-height:0em;font-size:0em; height:0em; padding:0px;
margin:0px; color:#FFFFFF;}
--
Martin Clark

[Chris Morris]

Martin Clark <ma****@spl.atwrites:

Chris Morris wrote...

Martin Clark <ma****@spl.atwrites:

I was talking about access key links, such as:

<p class="skiplink">[<a href="index.htm" accesskey="1">Home
Page</a>]</p>
<p class="skiplink">[<a href="#startcontent" accesskey="2">Skip to
content</a>]</p>

This looks more like a list than a set of paragraphs. Why the '[' and
']' around the links?

I didn't ask for a critique.

Welcome to usenet :)

I plucked that out as an example of what I was asking about.
IIRC the '[' and ']' were added after Wave Web Accessibility Tool
(http://dev.wave.webaim.org/index.jsp) complained about adjacent
links with nothing separating them. Anyway, it hardly matters if the
links are not shown.

The links are shown in some contexts (no CSS and/or non-graphical
display) though. Also consider
http://www.w3.org/TR/WCAG10/wai-page...list-structure
(guideline 3.6)

One thing to bear in mind is that the W3C guideline that the tool is
presumably basing its rule on:
http://www.w3.org/TR/WCAG10/wai-page...h-divide-links
begins "Until user agents" - I believe that it's considerably less
necessary now then it was in 1998 when the guidelines were written.
The links are in separate block-level elements, after all.

If the links were in the same block-level element - so
<p class='skiplink'><a href='index.htm'>Home page</a<a
href='#startcontent'>Skip to content</a></p>
then I *would* recommend a separator between them, to increase the
distinctiveness in visual browsing environments. Either ' | ' or in
many cases ', ' would be an appropriate separator.

with the CSS: .skiplink {display:none}

These don't need to be visible to the normal visitor but can be helpful
to those using audio browsers.

Actually, access keys are so badly implemented they're often rather
unhelpful to people using audio browsers.

[snip interesting comments on Access keys]

However, there is an expectation (requirement?) now in the UK for the
web sites of organisations to address issues of accessibility, and in
practice this usually includes the use of Access keys.

Hang on - so addressing issues of accessibility means introducing
features that are *bad* for accessibility because a Priority 3 (low)
W3C guideline written *before* browser manufacturers broke the
implementation says you should? The WCAG 1.0 guidelines were written
in 1998 when *no* browsers (Netscape 4 and IE 4 being the most recent)
actually did anything with accesskeys. It's "until user agents" in
reverse.

The W3C guidelines are not best used as a box-ticking exercise (even
if they do provide a handy table with boxes to tick) and this is
exactly why! Unfortunately, automated accessibility assessment tools
encourage this approach but inevitably have large false-positive and
even larger false-negative rates - consider:

<img src="graph.jpg">
(fails 1.1, 3.2 of the WCAG 1.0 guidelines, automatically detected as
such by many automated tools)

<img src="graph.jpg" alt="Turn image loading on you idiot">
(fails 1.1 of the WCAG 1.0 guidelines, breaks the spirit of 3.2 and
insults your users, *but* gets a full pass from all the major
automated accessibility checking software)

The presence or absence of accesskeys is an easy thing to test for, so
they do, regardless of whether it's a good idea to include them in a
particular context. Conversely, none of them test for
http://www.w3.org/TR/WCAG10/wai-page...traightforward
because it's not possible to automatically test [1].

Worse, some of the automated testers will fail you on
http://www.w3.org/TR/WCAG10/wai-page...tech-tab-order
if you don't include some 'tabindex' attributes on your page even
though it's perfectly possible (and advisable) to make a page that
passes this guideline without using 'tabindex' at all, and despite
'tabindex' often breaking usability and accessibility quite badly.

To return to my original comment about lists vs paragraphs, at least
one major automated accessibility checker will fail the first of the
following code blocks under the 'adjacent unseparated links'
guideline, but pass the second. On the one hand, the second is more
meaningful code and often has better display in non-CSS
circumstances. On the other hand, both should meet the guideline in
the same way:

<p><a href='...'>link 1</a></p>
<p><a href='...'>link 2</a></p>

<ul>
<li><a href='...'>link 1</a></li>
<li><a href='...'>link 1</a></li>
</ul>

http://www.cs.tut.fi/~jkorpela/www/acctools.html is good reading on
this subject. It looks at two particular programs, but most of it applies
to this sort of tool in general.

Incidentally, I came across a local council website
(http://www.portsmouth.gov.uk) that had a rather different way of making
the links invisible:
.Invisible { line-height:0em;font-size:0em; height:0em; padding:0px;
margin:0px; color:#FFFFFF;}

Ouch!

[1] http://groups.google.com/group/comp....0eb7342c173af7
makes the point that it's not practically possible to conform to this
point *at all*, of course - however, it is possible to manually
determine which of two pages better approach the guideline, but rarely
possible to do so automatically.

--
Chris

[Toby Inkster]

Chris Morris wrote:

The W3C guidelines are not best used as a box-ticking exercise (even
if they do provide a handy table with boxes to tick) and this is
exactly why!

It's fine as a box ticking exercise so long as you don't resolve to make
sure all the boxes are ticked when they don't need to. You can work
through the checklist, ticking boxes when you've done something, and
putting, say, a squiggle by a box when you have a good reason not to do it.

The remaining unmarked boxes provide you with a helpful guide on what
points you may wish to improve (and then tick) or ignore (and then
squiggle).

That way you can be sure that you've gone through a fairly comprehensive
list of accessibility problems and given them due consideration. If anyone
then asks why you didn't implement checkpoint a.b, you can look it up and
say, "well, I thought about it, but it would actually *hinder* usability
for group X".

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Chris Morris]

Toby Inkster <us**********@tobyinkster.co.ukwrites:

Chris Morris wrote:

The W3C guidelines are not best used as a box-ticking exercise (even
if they do provide a handy table with boxes to tick) and this is
exactly why!

It's fine as a box ticking exercise so long as you don't resolve to make
sure all the boxes are ticked when they don't need to. You can work
through the checklist, ticking boxes when you've done something, and
putting, say, a squiggle by a box when you have a good reason not to do it.

True, and I use them like that a lot myself.

However, there's lots of stuff that isn't really written in to the
guidelines anywhere. Making visited and unvisited links distinct from
each other and from non-link text is pretty important for
accessibility and usability, but doesn't get a mention in the
guidelines (unless you interpret the bits about consistent use of
navigation to include "consistent with internet conventions")

Using sensible font sizes doesn't get a mention past "use relative
sizes", which "body {font-size: 0.6em;}" passes even though it's
virtually guaranteed to be unreadable.

--
Chris

[Martin Clark]

Chris Morris wrote...

>Martin Clark <ma****@spl.atwrites:

>

I didn't ask for a critique.

Welcome to usenet :)

Well, thanks, but you're a bit late. I've been heavily into usenet for
the last nine years. I'm also familiar enough with these groups to know
that giving a url or quoting bits of code can sometimes lead to the
poster being jumped on! That's why I'm not going to get all hot and
bothered and give the rest of you a spot of entertainment!

Thanks for your detailed comments on accessibility and W3C guidelines
and for the pointers. I have saved the post to refer back to when I am
doing more accessibility stuff. I take your point about a list being
better than paragraphs for those accesskey links.
--
Martin Clark