Wandering Thoughts archives

An advantage of CSS layouts for accessibility

One of the charms of blogging is that you get to make mistakes in public. So, I'll start off by saying that I have to retract some of what I said in CSSvsTables, because a CSS column-based layout can be more accessible than a table-based one in some situations.

This is because one important part of accessibility is putting the important or changing content first in your raw HTML, and your navigation and other boring stuff second (so that screen readers and other things that more or less just go through your text in order can read out the interesting stuff first).

Table cells are laid out in order in the raw HTML, left to right and top to bottom, so the top left table cell is first in the HTML and the bottom right one the last. Thus, if you want a sidebar on the left of your design it has to come before your main content in the raw HTML.

CSS lets you reorder content, so that the linear order in the raw HTML is not necessarily the order on the screen. This means that your left sidebar can be towards the end of the page and shuffled into its physical position later, and you can generally make it so that your interesting content is very early in the raw HTML, no matter where it is on the page.

(And all of this is ignoring the tricks that are possible once you start injecting things into the page with JavaScript.)

This is probably more relevant to three-column layouts than two-column ones, because if you have a two-column layout your content should be on the left anyways for reasons covered previously.

Using CSS instead of tables is still using a hack

It's an article of faith in modern web page creation that using tables for layout, especially column-based layout, is an evil hack and that using CSS instead is virtuous, proper, and accessible. (These people probably turn up their noses at WanderingThoughts' table-based layout, which has its reasons.)

I have news for these people: it isn't so. Using CSS floats for layout is still using a hack. In fact, it's using a worse hack; at least tables make it clear what's going on. With CSS, there are two problems: first, CSS is an assembly language to start with, and second CSS creates columns only through indirect implication, which has various problems.

(You don't actually create columns in CSS; you create enough constraints that the browser theoretically has no choice but to put your content into columns. If you miss a constraint, some of your content stages a great escape.)

Thus, the net result of moving from a table based column layout to a CSS based one is replacing a clear hack with an indirect and opaque one.

How about accessibility, one of those claimed benefits? As far as I can see, there are two problems with that idea:

• basic table based column layouts are common enough that any accessibility technology that wants to be usable in the real world already handles them.
• because the CSS involved is indirect and opaque, it's almost certainly harder for accessibility technology to work out that your stuff is in a multi-column layout and what's in what column.

(In any case, per here, the most important thing for screen readers and the like is to put the important content first in your HTML and the boring navigation afterwards.)

For more reading on this, start with Aristotle Pagaltzis and follow his links.

An interesting observation about web cracker behavior

I recently got around to setting up a web site for a top level .org domain that has existed for more than a decade but previously never had a website or even had a 'www.<domain>.org' host defined in its DNS records. I did this with a name-based virtual host on a machine that had not previously been running a web server on port 80.

Within minutes, crackers were poking that virtual host in an attempt to exploit a PHP vulnerability; by contrast, it took three days before the first cracker showed up to poke the web server itself.

(Specifically, the crackers were requesting the URL 'index.php?id=<where>?&cmd=id', where the <where> bit was an URL; the URLs varied. Judging from the content of the URLs, this is some sort of PHP file inclusion attack, which was being exploited for various things.)

I wouldn't have been surprised by crackers poking my new web server by its IP address; in the good old days, I saw Nimda/Code Red exploit attempts against a new web server within minutes of bringing it up. What surprises me is that the crackers were specifically poking my virtual host instead of the web server itself.

(Equally interesting is that my old friend MSNBot showed up to visit the virtual host, but not the real web server, within twelve hours.)

My only guess is that both the crackers (well, their software) and MSNBot keep lists of top level domains and periodically poke them to see if they've grown a web site. It's possible that the widespread growth of virtual hosting has either forced this approach, or simply made it a better avenue than scanning IP addresses looking for new web servers.

(To some extent it probably depends on what sort of vulnerability you want to exploit. If you want to exploit a problem with the web server itself, you can just scan IPs since it doesn't matter what site on the web server you hit. However, if you want to exploit a common error in site setup, scanning virtual hosts/domain names may well be better.)