It’s been a long time coming, but as of today the standards of accessibility expressed in the Web Content Accessibility Guidelines are officially updated.

A W3C recommendation is the most final state a document can reach in the W3C standards system, and should now be considered the standard document for accessibility, superceding WCAG 1.

A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards published by other organizations.

Although there has been a great deal of controversy over the past few years concerning the validity of the WCAG 2 revision, the final document has managed to deal with the greater proportion of problems. Not everything, certainly — but expecting perfection in such a vast area of concern is, frankly, an unrealistic concern.

Jared Smith recommends reviewing the original draft from January 2001 to make comparison — could be entertaining! However, if you’ve got limited time to spend, now is definitely the time to make certain you’re thoroughly familiar with the new standard for web accessibility. It’s actually final.

• WCAG 2 Recommendation Document
• Press Release

Perfecting a web site is a long and involved process. There’s no getting around the fact that if you want every aspect of your site to be right — accessibility, search optimization, and just all-around pizzazz, you’ve probably got some significant work to do. However, that’s not to say that there aren’t things you can check quickly and efficiently to make sure you’re not making some of the more egregious errors!

Here are 8 speedy checkups (in no particular order) which you can easily perform on your site to inspect it for problems. No methods suggested require special knowledge of HTML or web programming. Excluding acquiring and installing software, these tasks shouldn’t take more than a few minutes for most sites.

That doesn’t include fixing any problems found, of course…

Read more: Web site Tune-up: 8 Quick Checkups

Some time ago, while pondering whether web accessibility posed limitations on design, the thought occurred to me that there are presumably some colors which simply cannot be used for text or text backgrounds in any site.

The nature of the Web Content Accessibility Guidelines (WCAG) specifications of color contrast fairly well ensures that some colors in the middle range of the spectrum (in hexadecimal, generally between #666666 and #999999) simply won’t be compatible with any other color.

When this article was initially written, this was more true than it is now. At the time, the limit for normal text contrast was a luminosity ratio of 5:1. The final version of WCAG, however, adjusted this to 4.5:1, which opened up additional possibilities. Nonetheless, if you look at your options using colors like #707070, you don’t have very many choices.

My first thought on this point was to create a chart of colors which simply couldn’t be used in these contexts. I decided against this, on the grounds that it didn’t really seem all that valuable to me. But the thought of viewing color contrast problems in a different way than most color contrast checkers stuck with me.

It seems that most color contrast checking tools work in one of two ways: they either take a webpage and check the contrast factors between text and background on that page, or they allow you to enter a pair of colors and find out how they mesh up.

What I’ve done instead is set up a color contrast checker which only requires you to enter one color, then displays a selection of possible color combinations using that color. It’s pretty straightforward: you can choose to view results ordered according to WCAG 1′s color brightness and color difference tests or according to WCAG 2′s contrast ratio algorithm. Either way, all three factors are displayed, providing a good sense for how the two systems differ.

The results can be quite interesting. Compare the results for #888888 under WCAG 1 and under WCAG 2, for example:

• #888888 Tested for Color Brightness and Color Difference
• #888888 Tested for Luminosity Contrast

Altogether, I’m hoping that this tool provides an interesting way to approach color contrast issues and to view the differences between WCAG versions 1 and 2.

Resources:

• Explanation of luminosity contrast ratio algorithm (Gez Lemon)
• WCAG 2, definition of relative luminance
• WCAG 2, definition of contrast ratio
• WCAG 2, understanding Guideline 1.4
  • 1.4.3 Contrast (minimum)
  • 1.4.6 Contrast (enhanced)
• List of color contrast checking tools (Roger Johansson)

Color Comparison Formulas

Color brightness formula: (must be greater than 125)

((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000

Color difference formula: (must be greater than 500)

(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))

Contrast Ratio with Relative Luminance formulas: (greater than 3:1 for print sizes over 14pt Bold equivalence or 18pt normal, greater than 4.5:1 for smaller text)

(L1 + 0.05) / (L2 + 0.05) where L1 = 0.2126 * R1 + 0.7152 * G1 + 0.0722 * B1 on the RGB values of the lighter color and L2 = 0.2126 * R2 + 0.7152 * G2 + 0.0722 * B2 on the RGB values of the darker color.

I’ve seen a lot of articles discussing the importance of HTML and XHTML semantics. I’ve seen articles describing what it means for a document to be semantic. Most of these articles, however, don’t provide a serious overview of what HTML elements actually may be considered semantic — and what those semantic elements actually mean.

And, even more particularly, why it matters.

Semantics is an erudite area of study. Literally, semantics can be fairly defined as the study of meaning in communication. Communication can readily be extended to cover symbolic notations, representations of language, organization of language, body language and information structures. In developing a web page, we are organizing a means to communicate the content of that page: ideally, we are organizing the page in such a manner that it will be understood regardless of the method by which the page is accessed. It should be equally understandable whether seen, heard, or felt.

The semantics of HTML structure, then, are clearly an important part of web design. Sending mixed signals to the user agent or the user by using a blockquote purely for it’s native indentation is an abuse of semantics: even the visual impact is dependent on the assumption that user agents will consistently render a blockquote in an indented manner.

It’s not precisely an issue that you’ve used a semantic element for presentational means, because, in fact, you’ve done more than that: you’ve presented a block of text which is not quoted material as if it were.

Semantic elements of HTML carry meaning regardless of your knowledge of that meaning. The result is that the misuse of an element creates the potential to mislead or confuse an end-user.

The most obvious examples in common use are those which make use of elements with semantic meaning which also offer a browser-contributed default presentation in order to use that presentational style. The blockquote example above is not uncommon; similarly, the use of empty p elements to create extra white space or heading elements used as a questionable SEO technique in substitution for normal paragraphs.

Other examples which bear mentioning include the use of empty anchor elements to trigger Javascript events — in this case, it’s partially a limitation of the identity of an anchor element, but an empty anchor element should always be considered an error, as it results in a behavior-less anchor if the Javascript is not available.

Now, you may point to the following paragraph, from the HTML 4.01 specifications, as a response to my opinion:

Authors may also create an A element that specifies no anchors, i.e., that doesn’t specify href, name, or id. Values for these attributes may be set at a later time through scripts.

The fact that it is allowed by the specification does not make it a best practice. With all due respect to the W3C, this should not be permitted. For reference, the HTML 5 specification currently reads:

If the a element has no href attribute, then the element is a placeholder for where a link might otherwise have been placed, if it had been relevant.

In addition, although I won’t quote everything, the specification states that an anchor which does have the href attribute must specify a URI as the value of that attribute. It appears to essentially state that an anchor element should have no semantic meaning if the href attribute is not set and valid. But I could be wrong.

The best means to avoid the misuse of elements is to have a clear understanding of when and why a given element should be used in web development. To hopefully expand on your knowledge in that respect, I’m attempting to provide a semantic guide to HTML elements for your reference and rich disagreement.

Be aware, however, that semantics are largely a matter of opinion. It’s not a question of blindly following the guidelines set by a group; it’s a question of interpreting those guidelines to the best of your ability and belief. This guide reflect how I think HTML elements should be used; and I welcome your opinions.

Other HTML Semantics Articles

• Guidelines from WCAG 2.0 on the use of HTML for semantic structure
• Traditional HTML Semantics (Part I of a three-part series on web semantics by John Alsopp)
• HTML: The Foundation of the Web – Niels Matthijs
• Semantic HTML and Search Engine Optimization – From the Opera Developer Community, by Joost de Valk
• Who will read your semantic HTML? – Jesse Skinner
• When semantic markup goes bad – Matthew Paul Thomas
• Semantics – why bother? – Mel Pedley at Accessites
• HTML Semantics from Western Civilization, Pty.
• Graph the Semantic HTML Structure of your Web Page – Joe Dolson

The Wikipedia article on Standards in software contains a very good definition of standards, particularly as we might need to view them when talking about web standards:

Standards (software)

Software standards enable software to interoperate. Many things are (somewhat) arbitrary, so the important thing is that everyone agree on what they are. Software standards is one of the Unsolved problems in software engineering

On the whole, the article at Wikipedia is a good example of what isn’t so great about Wikipedia — poorly written, incomplete: the article is more a collection of notes in preparation for writing an article than it is a real document. Nonetheless, the above definition contains a gem of perception concerning exactly what it is that standards actually do. Standards enable software to interoperate. Standards increase the ability of various programs to cope with what is fed to them.

And, fundamentally, that’s all they do. Standards, by themselves, are not in any way equivalent to “appropriate” or “good.” Web standards enable one program to understand what has been notated in another program. An HTML document may be an incredibly simple and basically inert program, but it is essentially a software program.

But they don’t actually dictate a lot about how that code is actually used, or what elements go into the program.

Let’s try a comparison to cooking. If you’re cooking, you’ll follow a recipe. The recipe dictates units (cups, teaspoons, liters, etc.). The recipe also dictates ingredients, sometimes with substitutions. However, some aspects of a recipe are actually pretty imprecise — cooking on “medium heat,” “beat until stiff peaks form” or “use one large egg” are all examples of specific directions which do not necessarily convey the information needed to perfect a recipe.

Furthermore, a recipe does not necessarily include every detail of creating the meal — it may leave out key pieces of information which it assumes you know: stirring the sauce, checking the internal temperature, or removing the pits. These are necessary aspects of preparing the meal right, but which require external knowledge to comprehend.

If you want to bake a cake, you do need to follow the recipe (mostly.) If you substitute baking powder for flour, you will not end up with a particularly appetizing cake — but you’ll also have problems if you ONLY follow the recipe, and include the eggs with their shells.

Molly Holzschlag mentioned this idea recently, and I’ve certainly written about it before, but it’s a valuable point and worth reviewing.

Besides, I thought of this analogy to cooking the other day while I was making dinner, and just had to get it out of my system…

(Or, more accurately, why the DOCTYPE is no more broken than any other potential switching mechanism.)

In a recent article, “Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8“, Aaron Gustafson states that “the DOCTYPE [is] unsustainable as a switch for standards mode.”

His argument is based on the problem that many developers and authoring tools now make use of correct DOCTYPEs despite the fact that they are not in fact using standards-based, valid code. Therefore, you can not actually assume that a valid DOCTYPE actually indicates the presence of the type of HTML code it claims.

Yes. This is true.

However, he then continues to state that a reasonable solution for this issue is to create yet another standards-based rendering switch. How is this logical?

Let’s review: the reason the current DOCTYPE switching mechanism is broken is because developers and authoring tools don’t use it correctly. The solution? Create a new switch which…can also be misused very easily.

…we’re really only left with one option for guaranteeing a site we build today will look as good and work as well in five years as it does today: define a list of browser versions that the site was built and tested on, and then require that browser makers implement a way to use legacy rendering and scripting engines to display the site as it was intended—well into the future. Aaron Gustafson

That’s a great idea, except for the minor flaw that there’s absolutely nothing stopping developers from misusing it in exactly the same way they have misused the DOCTYPE. Authoring tools may add an auto-generated list of default browsers, developers may cut and paste from other sites without understanding what they are using (much like some currently do) or (undoubtedly) new browsers will be developed which either ignore these switches or mis-interpret them.

I think that there’s a certain amount of sense in stating the exact state of browsers when your site was launched. I can see distinct value to being able to state that your site was developed and tested on Firefox 3, Internet Explorer 8 and Opera 9.732. I can certainly understand that this can help future browsers understand how to interpret your older code: when Firefox 14 is released, it will (hypothetically) simply incorporate the rendering rules from version 3, apply them, and there you are: a perfectly rendering web site. Complete with all the limitations it had when it was built, and incapable of taking advantage of any superior changes in rendering that a well-authored and standards compliant site perhaps could have benefited from.

I do feel that it is a serious mistake to consider this to be any kind of long-term solution, however. In reality, it’s just another requirement which can be mis-used exactly like any other.

The solution (which is not, of course, a popular one) is actually attentive developers who are prepared to make changes to their sites when new browsers are released. Developing to standards is a great way to ensure minimum requirements for redevelopment: why should we add yet another feature to pander to developers who refuse to observe basic minimum standards of coding?

In October of 2006, I published a brief article about Marcel Salathé’s interesting Java Applet to generate node graphs of web page structure. In that article, I stated:

I’d love to be able to produce graphs where I chose the color coding pattern for particular tags. I could set all non-semantic tags to be bright red, to easily spot the condition of a site in that respect. I could focus my attentions on inline versus block elements, or I could differentiate between different levels of headings.

More recently, I received comments on that post from a visitor who thought my idea to change this was a good one — so, at long last, I’ve gotten around to doing it.

Semantic HTML Graphs

And here’s an example of output:

The graph pictured here is for Metrolinx, the Greater Toronto Transit Authority — and Joe Clark’s failed redesign of the year. It makes for a pretty interesting case study. I know the output is small; but bear with me.

In this graph, you can clearly see long strings of orange nodes, which indicate nested table elements. You can also see significant clusters of bright red nodes, indicating deprecated tags. Altogether, the site is a maze of primarily long wavelength colors. In general, in the color scheme I’ve set up, greater densities of long wavelength colors (red, orange, pink) shows a dependence on tables for layout and presentational elements. Short wavelength color (blue, green) indicate more semantically meaningful structures.

I made a number of small changes to the script which I think add value. First, I added the ability to change the root node you’re mapping. I don’t know that this is incredibly valuable, but it does provide an interesting alternate piece of information. The node switching is limited; it will only check the first node specified of that particular content type.

The second change is to provide a variety of color schemes. The default is pretty complicated, although I drew the line well before attempting to provide a subtly different shade for every single element. I hope that the colors provided at least give you an idea of what you’re looking at, however. The alternate color schemes (two, at the moment) are much simpler: one which simply differentiates between allowed and deprecated elements and another which highlights all inline elements (a, dfn, samp, etc.).

Now, I’ve never programmed in Java before, and although the changes I made to Sala’s source code are relatively slight, it’s highly probable that there are bugs; and I’ve certainly not managed to remove any bugs from the original code.

The last thing I need to mention is concerning the accessibility of this applet. It’s just not accessible. In fact, I know little about how to make Java accessible in the first place; but even so, the entire concept of this applet is highly dependent on color. There can be no question that if you are color-blind or otherwise sight impaired this will be a problem. Additionally, there is absolutely no means present for any screen-reader to understand the input. I do hope to change this at a later date, and author a text-based output which will provide a separate, accessible interface with the information, but that just hasn’t happened yet.

Also worth looking at:

• Validation Graphs – a stand-alone Java application also based on the html graph script which spiders pages and checks them for validity.
• Web2DNA – same basic idea, different implementation.