Ten Tonne Baby!

Where's Mama?

Archive for the xhtml tag

• The Last Word on Headings

  I promise. Those of you who have had their fill should leave now.

  So the weird and fascinating thing about this is just how murky things are when you look for correct / best-practice information on this topic. The reason seems to be that the various HTML specifications that have been released are unclear, ambiguous and contradict each other. It seems that everyone has a slightly different understanding or interpretation.

  There isn’t much detailed reading material on the subject, but the best I came across can be found here.

  There first interpretation is that the heading level indicates the level of importance, but nothing else. There is no implied document ‘tree’ or nested structure. Based on this approach it would be perfectly acceptable to have an H1 midway through the document.

  The other interpretation is that headings imply a hierarchical document structure or tree. Therefore although they are technically siblings, and H2 following an H1 indicates a subsection of content within the main heading.

  The latter is much cleaner and allows you to focus on providing a clear, organised, well-structured document. It is closest to the natural way you would author other types of document. Personally I find this a much better approach. There are some practical complications as I’ve mentioned recently – you should really have a descriptive H1 as the first thing you encounter in the page, but having worked around these issues the end result is quite pleasing.

  In addition this interpretation matches with the XHTML 2 proposed changes that are under debate at the moment. In this model, the hierarchy is made explicit, with nested section elements, and a single h element is indicate a heading at any level. Personally I think have a big nested structure will overcomplicate matters, make it very easy for minor typos to build a drastically incorrect DOM structure, and generally open the doors for user agent bugs. I think bloated, deeply nested documents move too far away from how simple and easy to adopt HTML is, which is the reason for widespread publishing.

  Posted:

  December 7, 2007 @ 9:04

  Categories:

  Development

  Tags:

  accessibility, headings, markup, xhtml

  Comments:

  No comments so far

• The Trouble With H1s

  OK, so I’ve posted the background to the problem I’m pondering. This issue has come back after reading an SEO report of the site we’re working on. One of the recommendations was to use a unique, relevant level one heading for each page. Fair point – we’d adopted quite a common model of using the service brand name as the root heading for each document.

  So I have to admit, if you were authoring 30 different documents, the first thing you would find in each would be a relevant title / main heading for the doc. In a similar way, if you’re consuming an XHTML document, it would be great if the very first piece of content was a very relevant level 1 heading.

  This helps a couple of issues – firstly, search engines can give greater weight to what the page is actually all about. If the true page name / purpose is buried halfway through the doc as a level 2 heading among several others, there is no way to ascertain that it’s actually much more important (than Site Navigation, for example). The second is accessibility – rather than listening to the same chunk of guff at the beginning of every page, the very first thing a screenreader user will hear is a very descriptive heading, giving context to the content on the page. All good.

  To have a good document structure, with sections, and subsections, it is necessary to have the root heading at the start of the document. It makes no sense to have an H2 before an H1 in the doc. Think about a tree structure as how the document is organised.

  You end up with a great ‘un-styled’ document this way. The problem is when your visual design includes the page heading, and requires it to be mid-way through the document content. What can you do? You already have an H1 at the start of the doc, which means repeating yourself. Naturally you wouldn’t need the additional heading as you’ve already set the context.

  This mostly comes about as it’s very unusual for it to be ok for the H1 at the very start of the document to be the first thing visually displayed on a page. Therefore, you put it in to give good document structure, but style it so it isn’t visible.

  I’m not particularly happy with the best solution I’ve come up with, but it’s better than not using the H1 properly – if the design requires the title to visually appear midway down, we have to include it (again) in the document content. However it just seems wrong to have 2 headings on a page with the same text, therefore I’m using a paragraph.

  This gives an overall structure like so…

  • Lister’s All-time Favourite Movies
  • Brand Information
  • Site Navigation
  • Main Content
  • Specific page content (including a P re-iterating the page title, if the design requires it)
  • Page Footer

  I quite like having the heading ‘Main Content’ in the document structure, as it means you have a familiar, consistent place to go to for the page specific content. We can then provide a skip-to link directly under the H1.

  If you can think of a better solution to this, please let me know (soon!). I’m currently changing every page in the site, and it’s a bitch.

  Posted:

  December 6, 2007 @ 9:07

  Categories:

  Development

  Tags:

  accessibility, headings, markup, xhtml

  Comments:

  No comments so far

• Good Document Structure Via Headings

  When you go about writing a document, you quite naturally break it into sections and subsections, with a heading identifying each. You do this without thinking because it makes it much easier to take in the content, organise it, find specific pieces of information etc. Whenever you’re working on a webpage, adopting the same technique and thought process results in a well-structured, clear, accessible document.

  As a quite aside on accessibility, this aids in a couple of ways that I know about directly (probably others I’m not aware of). I spent some time using Jaws a while back, and there were two main techniques I ended up using to try and navigate a document. One was the headings dialog – this brings up a list of the headings on the page, and reads each. You can then click to go directly to one of them. The other technique was hitting the ‘H’ key to skip between headings on a page. In a well structured document this made it extremely easy to skip over sections that weren’t of interest.

  It’s a good idea to define each new section of your page with a heading, even if visually you don’t want to display it. Often when content is rendered, there are many visual cues that give you a good idea of what something is without an explicit heading. If you identify the headings added to aid document structure with a class name, you can style these to be hidden when the visual design is applied. Note that styling with display: none will mean that headings are also hidden to screenreaders. Instead, use absolute positioning to position the elements to the side of the visible page. These will still be treated as valid content to readers, but will effectively be hidden to everyone with CSS applied.

  If you fail to identify a new section with a heading, it’s content will appear to sit in the section defined by the previous heading – think about a word document. If you have a section defined by a heading, and you start a new paragraph that isn’t related, it still appears to be within the same section.

  To get a feel for how good a job you’ve done, briefly disable CSS (Ctrl-shift S in Firefox web developer toolbar). If the document makes sense without CSS applied and is simple to take in, chances are you’ve built a well-structured, accessible document.

  Posted:

  December 6, 2007 @ 8:49

  Categories:

  Development

  Tags:

  accessibility, headings, markup, xhtml

  Comments:

  No comments so far

• ASP.Net Markup Snob

  I tend to get quite sad when people approach ASP.Net and can drag and drop controls and build a site without really thinking about the markup that gets sent to a client. I know that part of their brief is to make it easier for people to build sites, but the added layer of abstraction of using a framework often means that people never gain an understanding of the underlying technologies involved.

  I’ve seen lots of respectable developers work on sites without running validators over their work or nosing around in the markup that is generated. People will learn the interface for consuming a particular server control without ever getting near the HTML. You’ll see posts from beginners along the lines of ‘how do I set the src attribute on an image’ – so you learn to set the ImageUrl property on the server control.

  I tend to approach development in ASP.Net from the other direction… how can I get the framework to generate this markup that I require in the most effective way? I think there should be minimal difference between how you would author a static site, and the generated markup from a dynamic site. Otherwise you’re compromising the quality of the site to accomodate constraints from the framework that you’re using.

  I think ASP.Net is a great framework. However I strongly believe it should be used to build custom controls that serve the specific markup needs you have for a site. Generally if you’re doing things correctly, the actual HTML is purely content and therefore very simple. It’s not actually that much effort to author nice simple custom controls that just serve your requirements and do nothing else.

  A simple example is how all of the ‘free’ server controls will always render an id attribute to the client – generally this will be autogenerated and long and bloated. Firstly this can interfere and make it hard to use ID based selectors in CSS, but also (more importantly) you should only render an ID attribute if you need a hook for styling or behaviour. Otherwise you’re simply bloating the stream of data that gets sent to the client, and wasting bandwidth and server resources.

  I always tend to build a base custom control class where you can specify whether and ID should be rendered, and also whether the ID should be scoped or not. If set to true, the ClientID property gets written to the output stream (the fully qualified value), otherwise the exact ID that was set on the control. The default for rendering the ID attribute is false. This means that the markup does not get bloated with unnecessary information, and as an author you have complete control over the value that gets rendered (so using ID selectors in CSS is back on the cards).

  Posted:

  September 6, 2006 @ 11:26

  Categories:

  Development

  Tags:

  asp.net, frameworks, markup, xhtml

  Comments:

  2 comments so far

• Jaws Navigation with Headings

  A while ago I spent a weekend learning to use Jaws (screenreading software) with the monitor switched off. I’m very interested in accessibility in terms of the practical benefits you can put in place for your users. Unfortunately it often boils down to people attempting to conform to a set of guidelines in order to claim some level of credibility. I think, although this is necessary, it makes it very easy for people to see this as a very dull, compulsory step in development, when in fact it’s a fascinating way to make your content available to everybody.

  I think most Jaws users develop different patterns and ways in which they use the tools, but I found by far the most frustrating thing was trying to get random access to a particular part of a page without listening to the whole document. When a page loads you visually take in a whole load of information and pointers about where to focus your attention depending on what you’re looking for. This is very difficult to do if you have to sequentially listen to each piece of content in turn.

  One of the features I was using the most was hitting ‘h’ to cycle through the headings in the document (and also the headings dialog which lists the headings on the page). Pages that used proper heading markup were so much easier to navigate. You could then locate the section you’re looking for, then listen to the content.

  Something I’ve started to do since then is ensure that I have a strong heading structure for my content regardless of what appears onscreen. For example, if there’s a list of navigation lists I’ll include a heading element of ‘Site Navigation’ whether or not this is included in the visual design. This improves the structure available to users cycling through the headings on your page. To find the navigation section, you can just hit ‘h’ repeatedly until the correct heading is reached.

  One point to note is that depending on how the heading is hidden onscreen, Jaws may or may not be able to detect it. Using display:none is bad – Jaws will not pick it up. Using position:absolute; left: -5000px will mean that the heading is not visible onscreen but is still available to Jaws users. I don’t particularly like relying on this kind of arbritrary styling, but until there’s a decent way to style for aural consumption, it seems like a practical step that can be applied right now.

  Posted:

  September 5, 2006 @ 12:52

  Categories:

  Development

  Tags:

  accessibility, blind, headings, jaws, screenreader, xhtml

  Comments:

  2 comments so far