Personally, I try to improve the way I structure documents on a daily basis. With every project I try to pick up new techniques or better something in some way. I find it’s a good way for me to keep up on my own work and push myself to continually read more and improve myself as a developer.
Semantics are by far a big part of my development process. I try to take extra caution in my markup as far as semantics are concerned because I believe the byproducts alone are fantastic. With a semantic document you’re setting yourself up for a more accessible document that has increased longevity and a higher level of organization. Beyond semantics, I also feel it’s important to ensure the content itself is usable to each and every person wanting to read a document.
Heading structure and accessibility
HTML is more or less a simple language, as most markup languages are. Each tag has a semantic meaning, and (most) client side technologies make use of the markup under the assumption that the document is organized in a meaningful way. The basic understanding of an accessible document stems from the proper use of markup, ensuring that it is universally usable no matter the circumstances under which it is obtained.
I recently read The Hard Facts about Heading Structure by Kevin Yank and it really hit home as far as my current process of document markup is concerned. I, like many others, could seriously improve my heading structure by keeping the WCAG Guidelines in mind.
Headings are a major navigational tool for readers using a screen reader. Having the ability to navigate a document by having the headings read to you makes a world of difference when those headings are improperly used. As suggested by the SitePoint article, I ran Monday By Noon through the W3C Semantic data extractor and was severely disappointed in my results.
Heading use and readability
Not only do screen readers provide the ability to skim a document using the headings, many people do the very same thing, including myself. It should come as no surprise that there is an F-Shaped Pattern for Reading Web Content (for most readers). There was an interesting article published to UsabilityNews regarding some recent research regarding headings. Good Headings help, bad Headings hurt by Caroline Jarrett reports on the effects of heading frequency on both paper an screen and the results are quite interesting: too many headings hurt as much as no headings.
It honestly makes perfect sense as I look back at some of my previous articles. The flow of the document is absolutely hindered by the excessive use of headings. Caroline Jarrett suggests taking your headings into consideration after they’ve been removed from their surrounding content. It’s a great way to make sure they can stand on their own and still prove useful.
Headings and SEO
Beyond the usefulness of headings when taking accessibility and readability into account, they also are quite significant as far as search engine optimization is concerned. Headings are a great way to put some more weight on keywords, but at the same time, they’re begging for abuse. Many times, headings are over saturated with keywords and make reading the document feel very ‘spammy’ — as if it were written for search engines instead of readers. It’s an easy trap to fall in, but should definitely be avoided. Search engines work to understand how people read and search in order to provide the most relevant documents on a per-search basis. Write your headings to be read by humans, not search engines.
My headings will be improved upon, they need it
I’m going to focus heavily on my heading structure from now on. It will be difficult as headings have their semantic places in documents, but overall heading order may be an issue. It makes sense that headings begin at one level, and progress in value as the document reads, but we are limited to six levels to work with. Many people feel six is far too many and that number should be decreased, but I’m happy with that number.
Taking the approach that headings should be used in a ‘top down’ fashion sheds some new light on this issue and raises some interesting questions. Should all secondary content headings be of the lowest level you reach? What about a company name or site title which most often is one of the first elements of every document? I don’t believe a company name deserves to be of heading level 1, but it should be placed near the top of the document. Do you think a company name or site title deserves to be a heading at all? These questions alone tell me I need to pay more attention to my heading structure and take into account their true values and applications before publishing any particular document.