Robert questions whether we should be using relative units because browser manufacturers are now defaulting to page zoom when invoking size alterations. He notes that while relative units can be exponentially helpful for readers when the developer has used them properly, but more often than not, documents are destroyed with a single size adjustment made by a reader. Page zooming helps with the issue of a degraded experience when relative units are misused (or not used at all). Robert has a general opinion on the matter as a whole:

I think most users would appreciate full page zooming, where everything in the web page is resized in perfect relation to each other. It will be easier to read while at the same time giving the end user a more consistent use experience.

There are some interesting comments that follow Robert’s post, with both positive and negative reaction to both relative unit use as well as page zooming. I think it’s an issue that’s got many developers on both sides of the fence.

How do I feel about relative units and page zoom?

I’ve written before about the benefits of using relative units in Web design, and I’ve become quite comfortable with using relative units for type in the majority of my production work.

There are a number of ways to take advantage of relative units when designing on the Web. I’ve opted to use relative units for (mostly) type as opposed to layout structure. Having precise control over element position is a true benefit of using pixels for layout elements.

I’ve come to enjoy working with relative units for type a bit more simply because the parent-child relationship has given me an opportunity to scale the type of a document with a single unit adjustment. This can be both beneficial as well as troublesome, which is why I think many developers are partial to pixel units for type. There are times when you’d like to adjust the type size for a parent, but not the children. If you’re working with relative units, you’re in a situation requiring subsequent edits to unit measurements of child elements. On the same token, you’re faced with the opposite speed bump when looking to adjust the type size of many elements at once. I think it partially comes down to personal preference and workflow in one regard; but should a personal preference of a developer effect the end product? In this case, I’m not so sure.

At the end of the day, what’s important is to produce documents which are most beneficial to readers. Unfortunately, there’s an elephant in the room making fixed units for type a (partially) poor choice for designers. Internet Explorer, as we all know, refuses to scale type sized in pixels. Although I haven’t confirmed it for myself, it’s been said that even IE8 will not make this adjustment. This bug is one of the more common long-standing bugs rooted in IE, and will continue to haunt designers for years to come. Many designers & developers have taken a stance stating that they prefer sizing type in pixels, and Internet Explorer can simply take a back seat, end of story. I haven’t reached that level of frustration, and I’ve embraced relative units for type, so I’ll continue to use em to size my type.

The issue at hand: page zoom

As with nearly everything, page zoom has both pros and cons. While one part of me views text-resizing as unexpected to the average reader, page zooming (and the resulting horizontal scrollbars) can be equally frustrating. I’ve tried to take a step back and view the issue from the standpoint of a reader as opposed to a designer, and I still find it difficult to come to a decision regarding page zoom. While I think it’s great that page zoom can help retain a document as a whole, and resolution-independent imagery could open the door to endless possibilities, I’m not sure if it’s the best possible solution.

Which brings up an entirely different issue; with browser makers beginning to default to page zoom, is it out of our hands anyway? At this point, I’m not sure how to answer that question, and I’d like to hear other opinions. I will continue to work with relative units for type, as I don’t see any harm in doing such, and it’s a personal preference of mine. Additionally, we’ve got Internet Explorer to contend with for some time, and using pixels for type degrades reader experience in that regard.

Do you think page zoom is the way of the future? Given the circumstances, how do you feel it compares to type resizing? With an arguably small percentage of readers making use of this browser feature, do you think page zoom will for some reason take prominence in a feature list, where text sizing has taken more of a back seat?

Which comes first? Navigation or content?

I have read in the past that certain developers feel that content belongs before site navigation. Their reasoning usually has to do with the belief that screen reader users prefer the content to be first instead of having to skip their way over a site navigation. Personally, I think site navigation fits best near the top of a document.

A lot of usability has to do with what people expect when faced with something. If your product doesn’t fit that user expectancy, the person is often confused. The majority of webpages have a global site navigation appearing first, followed by page content and various other elements. We all have been accustomed to this, including screen reader users. It follows normal convention and therefore becomes expected (most of the time).

This goes beyond navigation and page content, however. Secondary content is often misplaced in the source order because it’s easier for the developer to style a container element if it’s in the right place. The fact of the matter is, CSS gives a universal freedom to do anything you want to alter the display of a document without disturbing source order.

This is one of the major reasons I choose to apply markup to a document before even considering the style. Thinking about the style at the same time would set up a trap for non-liner source order. Keeping only the markup in focus initially will ensure that content sections are properly ordered and make sense.

Structural labels are very important for screen reader users

Tying in with source order, it’s really important to properly label your content sections with well written headings. Screen reader users are able to navigate a document extensively based on heading structure. If headings are vague or confusing, they will act as a hindrance for a screen reader user and make the document much more difficult to understand.

Your headings should strengthen the overall structure of your source order and further define how the document reads. Providing effective headings within a well thought source order can make any webpage that much easier for screen reader users or someone with a text based browser.

After reading usability test results, structural labels provided by headings have proven to be one of the most used features of a document. They’re universally regarded as useful by screen reader users, and the majority said a good heading structure really assisted with reading a document.

Skip links – useful or confusing?

Skip links can also sometimes be a usability debate. Some say that when a reader comes upon a hyperlink, they expect that link to target a different document. On the other hand, others say that skip links can be used very effectively and provide a nice service for screen reader users as well as those employing a text-based browser.

I think skip links can be very beneficial to both screen reader users and those with a text-based browser; it comes down to the link text. If you’re using a skip link to provide a shortcut to the primary or secondary content, use link text to describe it as such. It may seem like an obvious rule, but it should be said.

Usability testing has shown that experienced screen reader users hardly make use of skip links, but novice users rely on them heavily. Many times, the experienced users were able to much more effectively read a document using the heading structure as opposed to skip links. This is mostly due to the simple fact of experience. The more you use a piece of software, you become more proficient at it, and find more effective ways of accomplishing tasks. A novice screen reader user is much more likely to use a skip link and take advantage of what they have to offer.

Source order deserves a second look

While it may seem quote low level, keeping source order in mind will be of great benefit to many. Not only does it preserve accepted conventions of usability, a good source order helps to retain document longevity as well. In my opinion, one of the best ways to ensure a proper source order is to separate your development process into a markup stage and a style stage, in that order. Beyond that, testing with text-based browsers or disabling your style will help guide your placement of skip links.

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.