Joe Dolson: Accessible Web Design

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.

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)

This new book from Packt Publishing & Nirav Mehta is a quick and effective introduction to developing websites specifically targeted at mobile device users. I say “users” for a reason — - one of the strongest advantages to the book is a strong focus on considering your user and their needs as a key element of mobile web development.

My overall reaction to this book was positive. It covers a wide variety of key issues for mobile web programming in an easily understood manner. The book is targeted primarily at developers who already have some experience at web development and design, so it doesn’t delve into any serious detail when it comes to server-side programming or HTML coding, but instead makes a point of emphasizing places where the mobile web is different from internet interaction on a desktop device.

Mehta goes out of his way on many occasions to emphasize the serious importance of considering who (and what!) will be using your mobile web application.

“Any website accessed from a mobile device is mobile web — - whether it’s been tailored to work on a mobile or not!” Mobile Web Development, Nirav Mehta, page 10

The book covers a wide range of issues — - from developing for mobile devices using a “lowest common denominator” plan to implementing highly dynamic mobile applications which adapt automatically to the device currently in use. The text is easy to understand and follows a logical progression, starting with the mobile web development practices which are most similar to the development of standard web applications before moving into the areas which are very specifically targeted towards mobile devices.

This isn’t to say that the book doesn’t have a few flaws. I identified three areas where I really would have liked to seen better work.

Editing

In general, the copy editing on this text was pretty poor. The editing improved as I got further into the book (or I became more oblivious to it), but the introductory chapters had a lot of problems. There weren’t a lot of typos — - but the grammar was noticeably lacking. The book is rife with sentences like this:

“We will need a recharge of patience if we wanted to watch a movie preview on low speed mobile networks.”

I’m not a member of the grammar police, but I’m certainly sympathetic. Professionally published books simply shouldn’t contain the kinds of errors found in this book.

Code Examples

The author talks about following web standards as a critical element of mobile web development. That’s great. It is, however, a serious pet peeve of mine to see code examples which don’t reflect the text of the book. The very first code example in the book is this:

<link rel="stylesheet" type="text/css" media="handheld" href="mobile.css">

The text preceding it states “Here’s how you can add an alternative stylesheet link in your XHTML page.” I see a problem here. Yes, the author does explain at a later point in the book that all XHTML elements must be closed: but it’s a simple fact of life that most people referencing this book will be far more likely to simply reference the code as is. This is simply a mistake; but it’s not one that should have made it through a review of the book.

I’ll admit that I haven’t gone through and checked the validation of every code example. Most of them seemed solid and accurate. There are definitely examples which wouldn’t be valid under the XHTML DocType, but I’m not adept enough with XHTML-MP to know off-hand if the same is true within the mobile profile DocType.

Appendices

Simply put, there aren’t any. There were numerous points in the book where I thought to myself that an appendix would be great. A list of resources cited by topic, a section summarizing the syntax of VXML, tables showing the differences between XHTML and XHTML-MP or between CSS and WCSS. These kinds of resources would have been tremendous benefits to the overall reference value of the text.

Overall

This is a worthwhile book. Even though I wouldn’t recommend trusting the code examples, the truth is that you should never simply take code examples as written — - you learn best by taking an example and re-purposing it for your own needs. Mobile Web Development will introduce you to the key issues for mobile web programming and design in a manner which can give you a quick start on mobile web application development.

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

Here’s the first clue: it’s not creating a pixel-perfect replication of your ideal version of a site in all browsers.

In fact, cross-browser compatibility ultimately has very little to do with what a web site looks like, and a lot more to do with how it functions. It also has relatively little to do with browsers, and perhaps could better be explained as multiple user-agent compatibility.

“Compatibility” (in this context) is not a term which means “looks and behaves identically” — - instead, it may be better described as “performs equivalently under alternative conditions.” But developers and designers tend to most immediately seize upon appearance as the guiding line for cross-browser compatibility.

Of course, let’s be honest: there are a lot of very good reasons for this. Completely disregarding what we may know about the behavior of a site, clients tend to be very visually oriented. They POP their new site open at home one day during development and notice a whole variety of differences which they’re suddenly concerned about. If you’re lucky, they’re opening up Internet Explorer 6 after you’ve gone through the painstaking process of correct its inability to cope with standards-compliant code, rather than before you’ve gotten around to it. That can be awkward…

Another good reason is that despite what I’ve stated above, making the design behave more-or-less identically between different browsers is actually quite desirable. From a usability perspective, a seamless change in interactivity between different user-agents is very desirable. If you’ve ever tried to guide somebody through using a website which delivers a different experience to their browser than to yours, you are intimately familiar with one reason it’s a very bad idea.

But the absolute key to cross-browser compatibility is simply functionality. A lack of cross-browser compatibility doesn’t mean that something looks different; it means that it doesn’t work.

And a good thing, too. Otherwise, compatibility would be pretty well impossible between desktop browsers and mobile browsers.

With web design, it’s occasionally entirely possible to make two browsers render a design exactly the same…if you assume certain factors will remain constant, such as the user settings described in my last post. If any of those have been changed, everything pretty well goes out the window. As desirable as it is to make your designs look as similar as possible between the various desktop browsers, it always has to be acknowledged that there are limits.

There’s nothing at all that you can do to actually guarantee the same view for everybody; instead, you need to guarantee an equivalent view for everybody. Equivalent in that they will be able to get the same information and use the functions of the site to perform the same actions.

It wasn’t long ago that I wrote an article on authoring an effective text-resizing widget. In that article, I made a point not to espouse the use of text-resizing tools, since it’s generally more effective to allow people to use their browser’s built-in text-resizing functionality.

In fact, browser’s allow you a great deal more control than simply size. Modern browsers can give you extensive control over website text, including dictating background colors, text color, base text size, minimum text size, and link attributes. This post is intended to provide a quick overview of the specific controls for most modern browsers.

Most browsers have fundamentally the same options, although the interface and location in menus is quite variable. Some are more intuitive than others, and some interfaces simply don’t quite work right…

• Firefox, versions 2 and 3, Netscape 9
• Opera 9
• Safari 3
• Internet Explorer 6/7/8
• Internet Explorer, features specific to versions 7/8
• Internet Explorer, features specific to version 6
• Custom Stylesheets

Read more: Refining Text Presentation with your Web Browser: Windows

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?