You are here: Home / Dog Blog / Archives

Peek-a-boo: Another method for hiding HTML

Monday 5 April, 2004 ( 2:44PM GMT)

Picture this situation: You have a paragraph with links in, separated by commas. You want to keep the commas in the HTML because that's grammatically correct and because you want to adhere to WAI WCAG 1.0 checkpoint 10.5. What you don't want however is to display those commas. You could use this HTML:

<p><a href="this.html">This</a><span class="ttt">, </span><a href="that.html">That</a><span class="ttt">, </span><a href="theother.html">The Other</a><span class="ttt">.</span></p>

And then you could apply some CSS technique for hiding the 'ttt' class.

But the HTML is bloated. It would be much more preferable to just have:

<p class="ttt"><a href="this.html">This</a>, <a href="that.html">That</a>, <a href="theother.html">The Other</a>.</p>

But how to get rid of the commas? How about this CSS:

.ttt {
	position: relative;
	left: -999em;
}

.ttt a {
	position: relative;
	left: 999em;
}

The paragraph is yanked out of sight and then the individual anchor elements spring back into place. Peek-a-boo.

Comments

Comment 1

I can understand that there might be some reason to have no seperation between links, but generally, I think, it's a bad idea. I think in this case, the accessibility standard is for people that can actually see the screen (at least partially.) Someone with a screen reader will actually be able to differentiate between side-by-side links better than someone looking at the screen, since the links will have the same styling.

Does that make any sense? I'm tired right now, so I don't know if I'm too coherent.

So said Andrew on Monday 5 April, 2004 at 3:05PM GMT.

Comment 2

My understanding was that the requirement for a non-whitespace character between links was based on a bug in screenreaders at the time the accessibility guidelines were written. Readers at the time would speak adjacent links as one long link. They have since fixed the problem, making the WCAG guidelines device specific and woefully out of date. This is all rumor and hearsay, it would be great if someone could verify the reasoning behind the regulation. It's more valuable to those with disabilities for us to understand the spirit and not simply obey the letter of the law.

So said Nils T. Devine on Monday 5 April, 2004 at 3:58PM GMT.

Comment 3

Screen readers can read adjacent links pretty well actually, and there is no mention of this checkpoint in the working draft for WCAG 2.0. It still remains that if you want to claim to adhere to a standard, such as WCAG 1.0 AAA in this case, then you need to satisfy this point, even if it is out of date (see http://www.htmldog.com/ptg/archives/000035.php ).

What I find more important though is that you should maintain good English (or Spanish or Swahili or whatever) in HTML. X number of adjacent links that do not form part of a sentence should be separated by punctuation, such as commas.

So said Patrick on Monday 5 April, 2004 at 4:12PM GMT.

Comment 4

Why wouldn't you want the commas?
I'd think that if you didn't want commas you'd have marked it up as a UL with LI for each link.

So said Will on Monday 5 April, 2004 at 8:10PM GMT.

Comment 5

This is silly.
The whole idea behind it is silly. Don't make websites just to be in accordance with some silly unrealistic accessibility crap. Make websites for actual people.
I know Javascript scares you but why not just go through all child nodes of that P and remove the text nodes?

So said Dante Evans on Tuesday 6 April, 2004 at 3:22AM GMT.

Comment 6

Like I said, this isn't *just* about accessibility.

And sometimes you not only have to be in accordance with 'silly unrealistic accessibility crap' because you want to show you are considerate to those who are less abled than yourself and that you follow a helpful initiative, but because the people you're working for says "this has to be AAA".

And JavaScript isn't the answer to all of the world's woes. If I applied all of your JavaScript solutions to all of the issues that have been raised in the past, I would have incredibly bloated web pages. Besides, this is purely a presentation issue. That's what CSS is for.

So said Patrick on Tuesday 6 April, 2004 at 9:09AM GMT.

Comment 7

Unnecessary and useless. That is not what CSS is about.

So said Palmo on Tuesday 6 April, 2004 at 7:15PM GMT.

Comment 8

Necessary if you want to maintain properly structured language but present elements singularly.

Useful... erm... ditto.

CSS is about presentation.

So said Patrick on Tuesday 6 April, 2004 at 7:58PM GMT.

Comment 9

I didn't say you HAD to implement them, just think about the JS solutions.
BTW I noticed in everything you write you complain about IE. I was going to tell you about a JS solution but I found another: why don't you just do:
<!--[if IE]>
<style>
@import "justforie.css";
</style>
<![endif]>
Please stop giving Javascript a bad name. Please?
In case you DO ever want to do detect IE5+ with 99% percent certainty check for document.execCommand.
Cheers!

So said Dante Evans on Wednesday 7 April, 2004 at 12:48AM GMT.

Comment 10

Oh read this:
http://www.alistapart.com/discuss/popuplinks/7/#c7276
It sums up my views on the whole WIAA thing, and I like the way the author used his wording.

So said Dante on Wednesday 7 April, 2004 at 12:51AM GMT.

Comment 11

I won't linger on this too long because it's getting way off topic (again), but:

I complain about IE because it doesn't handle CSS as well as browsers such as Mozilla or Opera. That's a simple fact. I don't think even Microsoft could deny that.

I don't try to give JavaScript a bad name, I just think there is a time and a place for it.

Accessibility isn't Bobby.

Now. This Peek-a-boo thing....

So said Patrick on Wednesday 7 April, 2004 at 9:04AM GMT.

Comment 12

...is not a technique I would ever use, simply because I would never had to. And maybe if I did I'd remove it with Javascript.
Just in case you're wondering no browser handles CSS3 as well as Safari 1.2
Cheers!

So said Dante Evans on Wednesday 7 April, 2004 at 6:33PM GMT.

Comment 13

Agreed that this is highly foolish. When we start marking up commas in our pages things are seriously degrading. Remember people, do NOT follow a standard over the edge of a cliff, even if that standard seems well meaning.

Tom

So said Tom Dell'Aringa on Friday 16 April, 2004 at 2:51PM GMT.

Comment 14

This isn't following a standad over the edge of a cliff, I'm not even saying that the main reason for this is standards. It's the use of language.

OK, let's forget the commas for a minute. Take, for example, the 'XML' link that appears on the right hand side of this blog. It's styled as an the orange button with white text because that's a common symbol for suggesting that the link leads to an XML feed of the web log. It relies on visual recognition of a symbol.

But to someone who can't see the orange box, 'XML' on it's own makes no sense. To benefit someone who uses a screen reader, you could simply make this "XML feed" or something similar. Then instead of wrapping " feed" in tags to hide it, all you need to do is apply this method.

That's just one example. Hiding elements is a common and often necessary thing. All it is is a method of reverse-hiding, whereby instead of hiding the elements wrapped in tags, you hide those parts that aren't wrapped in tags, leaving the rest behind.

So said Patrick on Friday 16 April, 2004 at 3:22PM GMT.

Comment 15

I honestly can't believe that your article got such bad responses. It bothers me.

The application seems so obvious to me. When you want to make a web page that is viewed in a style similar to an OpenOffice.org Impress presentation, you could hide things that show up later on in the presentation. Of course there is that XML thingy that you mention.

I was really trying to demonstrate this on my own personal web site, by showing that you could do many relevant and useful things with only 1 marked up page, and a handful of style sheets. Most people don't seem to be aware that style sheets could be combined, but I digress.

My biggest complaint about this technique is that you don't actually get to make it disappear. That's not your fault, though. I fault the W3C. A big mistake that they made was making "display:none" inheritable, but not uninheritable. If it were uninheritable, then it would be possible to set the child elements to "display:block" or whatever. This is relevant for when people want to copy and paste text.

Sometimes I get the impression that the standards weren't designed by designers. Don't get me wrong, though. They did a marvelous job as it is.

Thanks for sharing this technique with us.

So said Eugene T.S. Wong on Thursday 27 May, 2004 at 10:55PM GMT.

Comment 16

In my opinion the best solution if one does not want to use list markup but separate adjacent links by one or two characters is using the CSS "visibility" property. This property at times seems to be underestimated. It does not have the disatvantage Eugene pointed out for the "display" property but in contrast to that property it preserves the space the invisible content would occupy if it was visible.

The stylesheet for the above example would simply look like this:

p.ttt {
visibility: hidden;
}

p.ttt a {
visibility: visible;
}


So said Jens on Wednesday 9 June, 2004 at 5:49PM GMT.

Comment 17

Hmm... yeah. That certainly is simpler! Funny how you can miss the more obvious things when you start to think around a problem...

So said Patrick on Wednesday 9 June, 2004 at 6:01PM GMT.

Comment 18

I like this article, it does not matter what people think about the actual example used (i.e. hidding commas) - it's the code technique that is important!

The other technique in post 16 is simplier and probably should be used, however using 'visibility: hidden' is something search engines are clamping down on (due to keywork stuffing and other black hat search engine ranking techniques), using this may get the website blocked from the search engines! - so I would go with the first code example.

So said [Anon] on Wednesday 27 July, 2005 at 3:24PM GMT.

See Also

^ Top

SiteGround: Fast, reliable, recommended hosting.