Blog ยป Archive by category 'Web standards'
Thanks to the power of internet criticism, the code discussed in this blog post has since been fixed! Sometimes just making a complaint is all it takes to get something fixed. I was highly critical of the code authors for this low-quality code; but they truly did care, and made changes. Thank you.
Authoring forms is an important part of keeping the web fully accessible — not just providing access to information, but allowing users to fully interact with the web in all it’s glory. Interactivity is what makes the web powerful and persuasive.
As such, I can’t help but be frustrated when I run across basic form construction which is simply well below the standards I’ve come to expect. A form like this one, for example, is incredibly irritating to my sense of what the web should be:
<form action="/store/add_event_to_cart/53" autocomplete="off" method="post"> <table>
<tr>
<td nowrap><span class="required">First Name:</span></td>
<td><input id="attendee_first_name" name="attendee[first_name]" size="40" type="text" value="" /></td>
</tr>
<tr>
<td nowrap><span class="required">Last Name:</span></td>
<td><input id="attendee_last_name" name="attendee[last_name]" size="40" type="text" value="" /></td>
</tr>
...[numerous similar fields deleted to avoid boring the hell out of you]...
<tr>
<td colspan="2"> </td>
</tr>
<tr>
<td colspan="2">
<input name="attendee[sponsor_email]" type="hidden" value="0" /><input checked="checked" id="attendee_sponsor_email" name="attendee[sponsor_email]" style="vertical-align: top;" type="checkbox" value="1" />
<p style="display: inline-block; width: 360px;">Please sign me up to get occasional information from select sponsors, partners, and other fun people.</p>
</td>
</tr>
<tr>
<td colspan="2">Discount code (if applicable): <input autocomplete="off" id="attendee_discount_code" name="attendee[discount_code]" size="10" type="text" /></td>
</tr>
</table>
<input name="commit" type="submit" value="Add Attendee" />
</form>But in this case, it’s not just the nature of the form itself. There’s a lot wrong here — the use of table for layout is a big problem, but even if you’re accepting the table as logical (and there is a particular logic which would except tables for forms,) the lack of a summary or headings in that table and the use of empty table cells to provide spacing is a big problem. Then we look at the form itself — not a label element in sight; instead we have plain text using a span and class to indicate if a field is required. There’s no coded indication that a field is required; it’s a purely visual indicator.
My sense of accessibility hurts.
And do you want to know where this code came from? Here it is.
Here are a few good articles on high quality form construction – but don’t bother reading them. After all, they didn’t.
This is something that pisses me off; but you can find it everywhere. Large organizations responsible for web publishing don’t always maintain the standards they talk about. Is it just talk, then? Does the fact that An Event Apart does what A List Apart condemns mean following standards and implementing accessibility doesn’t mean anything?
Thankfully, no. It does mean that web sites aren’t perfect; and the people doing the labor are frequently not the people who know best how it should be done. But it is a problem — as much as we can evangelize best practices, it doesn’t mean that they’ll be used.
There’s a lot of pressure in the web industry to produce fast results. Sometimes this means people take shortcuts; sometimes it means hiring people who may not be as fully trained or qualified as you really wish you had; and sometimes it means things just go wrong.
But I’m left with a definite feeling of frustration to find that a leading web standards event like An Event Apart should exhibit this kind of HTML on their web site.
How can this be avoided?
Ooh, that’s a tough one. Work processes, new employees, insufficient testing — all of these can allow inferior code onto a site. As a freelance designer, it’s positively rare that I have sole control over new content or template changes after the initial launch. As a member of a team, I can only imagine that it’s even more difficult — anybody with sufficient permissions to commit a change can change the overall level of competency exhibited on the site.
Application of a tool like Marco Battilani’s Big Red Angry Text technique can help, but it’s a little scary to put into a published site if you know that the editing won’t always be done by knowledgeable people. It may demonstrate mistakes, but can sometimes serve to do nothing more than piss off or frustrate your client or staff. It depends on the control and education you’ve been able to impose.
- Educate. Teach the people who will be doing work on the site as much as you can – the what and the why.
- Review the site. Review the work that’s been done; a 30 second glance at the code is likely to result in fixing at least some errors, and will hopefully prevent future errors of the same type.
- Provide tools for self-checking. Not a first choice, since all automated tools are flawed by their very nature, but they can still be of use.
It’s not always practical; but if following these steps is at all an option, it’s really worthwhile.
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.
Return to Top
