During a workshop on accessibility and WAI yesterday, the issue of proper use of HTML headings came up.

Lots of sites fall short when it comes to using HTML headings (and other elements) properly, something that can affect accessibility, search engine ranking, as well as code maintenance [not to forget future re-use on the grand Semantic Web].

How - and where - to properly use the elements might not always be that clear, and some of the questions raised during the discussion can be rephrased as:

• Do all web sites/documents have a clearly defined heading?
• Do all documents have to specify a H1?
  
• Is it really OK to put the logo inside H1?

What follows is my 2 cents on the subject.

(more…)

In a recent blog posting - Er validering verdiløst? - Chrisitian Johansen argues that it is important to create valid HTML and that valid HTML is a good indication of high quality code.

I agree that although valid HTML in itself does not guarantee a good product, it is important to write valid HTML. Both for your own and for other developers’ sake. In some cases, it might even affect the user experience.

Someone has to maintain the front-end code base, and valid HTML is most def. important when it comes to maintaining HTML/CSS/JavaScript and supporting all kinds of browsers/clients.

Valid HTML is also much more likely to be accessible HTML (although other factors, such as using Semantic HTML are more important) and might also play a role in SEO. It might also prove important for future use of existing code.

Further, validating your HTML may help you by pointing out unintended and/or unnoticed mistakes, and thus spare you hours of work, especially when dealing with design implementation (CSS) and cross-browser compatibility issues. At least the kind of errors that are under your control.

A point I’d like to add to the discussion, is how many programmers realize the importance of well-written back-end code — clean, easy to read, (correctly) object-oriented, using well-known patterns, sleek algorithms, etc. — while they have no problem ignoring the part of the application code base that is actually exposed to and open for the rest of the world to see. Way too often, too little effort is put into making the front-end code as good as that of the back-end systems. In my opinion, both things are equally important. </rant>.

The following quote is taken from MSDN’s “How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance“:

Best practices in CSS
[…]
Elements should be positioned with CSS 2, not tables

Makes me wonder whether MS devs read MSDN articles…
Or not.

As predicted in my initial posting, I am not very good at hosting a blog … long time no see.

Anyways: on the project I’m currently working on, I’ve had an interesting discussion with the interaction designer. The interaction designer had implemented the web application’s graphics design, based on our ID drafts, in HTML and CSS … which I was to transfer to JSP.

He had, however, marked up some headings which logically speaking were H2s, as H3s, and the corresponding H3s as H2s. This lead to sub headings taking the role of headings - and the other way around.

My first reaction was that this is not a good solution. (more…)

Although the title of this blog post might seem a tad ironic in that there is not much semantics to HTML or XHTML, I do feel like writing a little piece about how to correctly use (X)HTML.

Hopefully, it might help you understand that even valid (X)HTML can be bad (X)HTML, and that — and how — semantic HTML may help improve your site’s usability, accessibility and search engine ranking. Whether you’re developing for a commercial site or not, these factors should be of interest. They certainly are to your end-users. (more…)