How far should we push semantic markup?

Occasionally I run across a nifty semantic markup ponderable, such as those posed by Dan ” Simple Bits ” Cederholm in his quasiperiodic ” SimpleQuiz .” (If you haven’t checked it out already, do; it’s a fine example of good thought applied to meaningful, useful markup.)

I find these questions intriguing, and I strive to use the “right” markup wherever possible, selecting tags and structures that at least share a strong kinship with the meaning of their contents or the function of those contents within the document. But it is easy to overthink this.

In any case, I’m currently working on a web app that involves a fair number of forms. Most of the pages end with what we call “pagenav,” process-oriented navigational elements that take you forward or back in a process, or off to do another likely task once you are done. In general there’s a clickable thing of some kind to the right (to continue), often there is one or more to the left (go back, undo), etc.

Some time ago we vastly simplified the markup from a byzantine JavaScript and table structure to a simple div containing anchors, generally with class=”forward” or class=”back” as needed. But this is still a bit far from what is coming to be considered the right way to markup navigational links, an unordered list. And it isn’t terribly accessible, since some screen readers will read the collection of links as a single nonsensical sentence.

Here’s the rub: these various navigational elements are not of equal weight, as would be suggested by a UL. Most notably, we have an expected, encouraged action, “go forward.” Generally this is to submit the form, and generally it is what the user wants to do (and what we want the user to do). All of the other links are secondary to this, especially “go back” and “undo”-flavored links.

Furthermore, when we are congratulating the user after having completed a process we have one or a few possible convenience links leading them off to perform other tasks in the forward direction, and often a “go back and edit” retrograde link. These links are, more or less, of equal priority.

Ideally the markup would suggest a primary action, if we have one, and then segment the forward and back actions somehow. Ideally, the markup would be basically the same whether or not there was an expected forward action. And if, for some reason the page were shown to the user without benefit of CSS, the forward/back nature of the links should be somehow evident.

Perhaps this is too much for our beloved and simplistic (X)HTML to handle?

Nils ( DivineBlog ) pointed out that if we have a single, important submit action, it should be a honest-to-gosh submit button, outside of any secondary link structure. This is a great starting point; the remaining links could well live in one or more unordered lists with no ill-effects.

But how to handle forwardness/backness? Two ULs? More later.

Leave a comment