Blog ยป Archive by category 'Web standards'
In the final release of WCAG 2, the acceptable minimum color contrast ratio was changed from 5:1 to 4.5:1. I’ve updated both my color contrast tests — Color Contrast Comparison Tool and the Color Contrast Spectrum Tool to reflect the change in contrast ratio.
What does this change mean?
Essentially, this means that the working group decided that color combinations with lower contrast (more similar colors) were acceptable for general use on the web. This is certainly good news for designers, since it will provide for a greater variety design voices than previously.
The contrast ratio of 4.5:1 was chosen for level AA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision. (20/40 calculates to approximately 4.5:1.) 20/40 is commonly reported as typical visual acuity of elders at roughly age 80.
Understanding WCAG 2.0; Understanding Success Criterion 1.4.3
While the previous higher ratio requirement may have accommodated for an even larger audience, the decision of the committee appears to have been that it had crossed a line of diminishing returns, and that the lower requirement is sufficient for most common use.
This effects the minimum ratio to accommodate at Level AA, and the minimum ratio to accommodate at Level AAA for large print.
Still — don’t get carried away!
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.
- Part 1 (Contracts, Site Requirements,Information Architecture)
- Part 2 (Hosting and Security)
- Part 3 (Navigation, Scent)
- Part 4 (Semantics, Structure vs. Design, Universal design)
- Part 5 (Interaction, Errors, and Administration)
So, we’re finally getting to the meat of best practice web development. This is what people are usually thinking of when they ask about best practices in web design or web programming: actually building the web site itself.
Web design best practices encompass a wide range of needs — everything from the visual look of the design and use of well-chosen markup to the implementation of alternate styles for mobile devices or print shows up in this area. Covering it in one article is, perhaps, ambitious. Fortunately, I’ve written on parts of this subject frequently in the past, so I’ll be providing a lot of links.
It’s important for best practices to clearly separate the structure of your web design (the internal labeling and definition of page elements) from the design elements (the appearance of these elements.) In the last article in this series, I discussed a few key elements of design: not in terms of color, layout, or typography, but in terms of communicating information.
Best practices ultimately leads to creating a universal or accessible design, and this practice hinges on two key concepts: web semantics and the separation of your structure from your design.
The Semantics of HTML
You can argue for days (or years, if you take look at the search results for “HTML semantics” or “web semantics”) on the detailed semantics of how HTML tags should be used. I’ve written on this several times, myself, including articles discussing the value of empty elements, the age-old debate between table-based or CSS layout, among many others.
Semantics are very important. However, when you really look closely at HTML you’ll inevitably notice that it’s not a strongly semantic language — the mark-up language doesn’t even come close to describing all possible uses of the tags. Many tags end up inevitably serving multiple functions.
So what web semantics really require is interpretation. The HTML specification provides one version of this interpretation, with suggested uses and meanings for elements. I’ve provided my own interpretation, as well. There are without question differences of opinion between those documents.
Obviously, you can argue very convincingly that any interpretation which disagrees explicitly with the HTML 4 specification is wrong. Feel free. The core of best practices in web semantics is to use them and make decisions: it’s about thinking, not specific rigor.
We need to differentiate, however, between the semantics of HTML and web semantics. The semantics of HTML are specific and defined: meaning as applied to the elements of HTML. This is a finite list of items, although the complete definition of meaning is less so. Web semantics, on the other hand, describe the application of meaning on the web. This is a more global concept, and applies to all aspects of your web development process.
Web semantics includes everything used to add meaning to your site, providing better comprehension of code and content. Using describe class and ID naming conventions, descriptive function names in server or client-side scripting, or providing helpful comments within your code can all be considered points of web semantics. Best practices means providing a site which is meaningful in both the front and back end.
For specific suggestions about element use, refer to my guide to semantic HTML.
Separation of Structure from Design
This is such an old question to harp on, but the importance of separating the organization of your page from the way it looks has never really flagged.
At a superficial level, it may appear that any markup you use has an effect on the appearance of your site. After all, there’s a clear visual difference between unstyled text marked as a heading and unstyled text marked as a blockquote! However, this visual difference only truly exists because the description “unstyled” is truly a misnomer.
If you disable stylesheets on a web site, you’ll see an extremely plain view of the site. It is not precisely “unstyled,” however — the design has simply been reduced to the default styles applied by the browser. In general, every browser has very similar defaults — but they’re not exactly the same. This is one of the reasons that it’s common to begin a stylesheet with a set of reset styles.
If you conscientiously remove the browser default styling, it can make your own development easier: the slight differences between browsers can then be ignored.
The point is that you should never place anything in your markup which exists purely to create a different appearance. Attributes or tags which define font faces, colors, or styles are obvious problems — but the use of small or strong can also be problems. It’s not that you should never use small: but your use of the element shouldn’t depend on the text being rendered smaller than the surrounding text.
It might not happen, after all.
This is one of the key complaints about using tables for design layout. A table is designed to organize information by providing easy access to it in a matrix. The columns and rows visual appearance of a table is a formality used because it is an expected way to view this type of data organization.
When you take a table and use it to layout your design, you are violating the separation of structure from appearance: your design is now dependent on the default organization of tables. Should somebody attempt to re-organize your table (for example, to linearize the information,) they may encounter a radically illogical data structure.
Fundamentals of Universal Design for the Web
The goal of universal design is very simple: make the information in your website available to every person or device which attempts to access it. This includes mobile devices, search engines, assistive technology, disabled users, and standard desktop browsers.
Universal design is where we bring everything above together. Attention to web semantics and a strong separation between structure and design give your web site at least a fighting chance of being universally usable. Obviously, you can still screw things up!
In the same way that following web standards doesn’t mean that you’ve made a web site accessible, following best practices for general web development doesn’t mean that you’ve made a site which will be great on a hand-held device or with a screen reader.
Different devices (like people) have different special needs.
Creating a web site which is truly universal requires you to be aware of the special needs of every device you’re working for — but a few basic principles will get you 95% of the way there.
The Principles of Universal Design provided by The Center for Universal Design at North Carolina State University are a good guideline for thinking about universal design. Although these principles are truly designed to be universal, in that they are intended to be applied well outside the realm of web development, the basic principles are sound in any context.
If you break the concept of universal design down to a single core issue, it could be that dependencies break access. Whenever you set up a situation in which a specific technical or design element must be present (a dependency on Javascript, a requirement that a control matches the description provided, or a requirement that a user must see a given image, for example,) then you are creating the potential for design failure. Avoid creating anything which depends anything out of your control.
Knowing what is and isn’t in your control (and, more importantly, what seems like it’s in your control, but really isn’t) is critical to best practices in web development. Acknowledging that although you can set the color of the text, you can neither guarantee that a visitor will be capable of seeing that color nor that the text will in fact be that color at the point that a visitor sees it is a critical step in understanding universal design.
Best Practices in Web Development: Part 5 (published on Friday, September 5th) covers interaction design, error management, and long-term site administration.
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.
WCAG 1 does not, in fact, provide any specific guidelines concerning color contrast. The formulas commonly used to judge this were specified in Techniques For Accessibility Evaluation And Repair Tools, published in 2000. The document is intended to help authors conform to WCAG, but is not actually part of the WCAG document.
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. Since this article was authored, I’ve created this basic tool as well. Evaluate contrast between two colors.
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:
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:
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 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.
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
Return to Top
