It’s sometimes hard to remember that HTML 5 is still not in common use — and that writing about HTML 5 is something which almost exclusively targets forward-thinking and experienced web developers. HTML 4 is still in widespread use across the web. If you’re looking at volume, HTML 4.01 and XHTML 1.0 cover most of the web site editing by webmasters, internet entrepreneurs, content management systems, or on personal sites.

But, more importantly, the internet continues to be littered with tutorials on how to abuse HTML.

If you look for HTML tutorials, you will primarily find fair and reasonable articles on standards-based usage. This is good. You will not, however, exclusively find tutorials which exhibit best practices in front-end development. This is, in part, the fault of an un-revised web: the well-reasoned article you wrote in 1998 may still be present, exhibiting years of inbound links and an honest but obsolete point of view. To the undiscerning reader, the authority of your article may be more apparent than it’s obsolescence.

I have mixed feelings about the idea of deprecating web content. There’s a part of me which is hesitant to edit the past by deleting and redirecting from older articles. After all, this isn’t done in print materials — if a volume is edited and re-released, the prior version is still available. In fact, the prior versions won’t even have any reference of any kind to let you know that they’ve been updated! The web has the power to avoid that problem entirely: in theory, you can delete, revise, or redirect away from any obsolete article on the web, making it impossible for any new explorer to come across out-dated material.

In practice, however, that doesn’t always happen. The best publications focus (as they should) on producing quality new content, and let their archives stand. While this means that they retain an honest history of their publishing, it also means that authoritative publications may still be promoting outdated ideas.

Today, for example, I ran across a web site which had a professional-looking design (albeit rather generic) and offered a prominent section of HTML tutorials. The first article in the set of tutorials was discussing how to use the font element to change the size, color, and font used in your text.

It even used Comic Sans as the example for an alternate font to use. Seriously.

For obvious reasons, I’m not actually linking to this site — the whole point of my article is to try and avoid the promotion of outdated material, after all.

Now, to me, it’s fairly apparent that this article is sitting here pretty much as advertising fodder. The site isn’t one which has anything like a prominent position in results for HTML tutorial, or is a place somebody would be expected to land when looking for an HTML tutorial. But it’s there, and somebody has undoubtedly made use of it.

Is the article above a representative example?

In point of fact, a lot of web publications have behaved moderately responsibly about promoting better practices in web development. However, the actual results you’ll find in a search are all over the map — and examples like what I cited above are definitely present. In an example search for “html tutorial change font color”, among the 9 relevant results in the the top 10 included:

• 3 sites which mentioned that the font element had been deprecated;
• 5 sites which suggested the use of stylesheets instead;
• 3 sites which linked to a tutorial page on Cascading Style Sheets;
• 3 sites which linked to a tutorial page on adjusting fonts with Cascading Style Sheets;
• 0 sites which had removed the information on changing font size with the font element;
• 4 sites which did none of these things, and recommended use of the font element whole-heartedly;

Interestingly, not one of the results was exclusively a discussion of changing font color using CSS. None of them. In fact, only one of these articles even included information on changing colors with CSS on the page, and the example provided in that article only pertained to changing the colors of of the anchor element. This very fact should make it evident that people searching for HTML information are still very likely to come across bad information.

It’s not 1998 anymore, but 1998′s HTML tutorials are still haunting us.

It’s clear from examining the search results that the larger players in the tutorial realm (Tizag.com and W3schools.com, for example) have done some due diligence in updating their articles, which is good. However, they could do better.

The Conclusion

So, I get back to my original point. It’s still important to talk about older technology: it’s still relevant to write or promote articles which offer tutorials on simple tasks, like changing font color using CSS or properly forming an unordered list. The reason it’s relevant is because the internet knowledge base is polluted — those who are in control of outdated material should take responsibility for updating their information, ideally, but we don’t all have that power. The best we can do is continue to promote best practices in all areas.

If you think about it, a significant part of web site updating is done by non-experts: the person tasked with maintaining the web site in a small business may not be at all knowledgeable. The beginning blogger may not know anything about HTML. Their learning will still come through basic searches, starting from a task-oriented question which is probably not technology specific. Those are people we need to reach if we seriously want to improve the quality of HTML on the internet.

It’s still important to talk about HTML 4
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

To help explain these changes in Federal web accessibility standards, I’m going to look at three specific questions. These questions will hopefully answer some of the questions concerning what’s coming up:

1. Has this changed anything about who must follow Section 508 guidelines?
2. What has been the primary reference for changes to Section 508 rules?
3. What are the specific changes to the Section 508 documents?

Has this changed anything about who must follow Section 508 guidelines?

No. The section 508 rules still exist under the same body of law — this is not a revision of the application of the law, it’s only a revision of the methods which are acceptable in following the law. Section 508 continues to apply only to Federal departments or agencies or entities providing services or products to Federal agencies. Further, it only applies to the specific services or products provided by those contracted entities, not to any external presence or non-Federally funded projects.

What has been the primary reference for changes to Section 508 rules?

Based on the document guidelines and on references made in the updated document, it seems that the primary reference was the Web Content Accessibility Guidelines, Version 2.0, as created by the World Wide Web Consortium. In fact, there is a specific section referring to WCAG harmonization, which indicates that web pages as defined under WCAG 2.0 which are conformant to Level AA will be considered to be in conformance with Section 508 (with a few elaborations on additional requirements.)

This is an excellent change, since it explicitly states a subset of requirements which need to be reviewed in addition to WCAG 2.0, Level AA requirements. From a consulting perspective, this simplifies the process: you can review WCAG 2.0 requirements, then check the additional requirements under Section 508.

The additional requirements are fairly straightforward. A significant percentage of them relate explicitly to video accessibility — an area which WCAG 2.0 frequently describes as Level AAA requirements. It seems clear that the Section 508 review group was concerned about the use of video in government communications, and wanted to be sure to avoid a situation where creating a video would allow Federal agencies to ignore Section 508 requirements — which is certainly a wise concern.

What are the specific changes to the Section 508 documents?

To work through all of the specific changes would be a Herculean labor — and I’m not prepared to undertake it right this moment. I’m not sure an article is the right place to do this, in fact. A permanent document demonstrating the changes may be more valuable, in the long run. Suffice it to say that the basic fundamentals of Section 508 have been updated to reflect the changes between versions 1.0 and 2.0 of the Web Content Accessibility Guidelines. The requirements which are beyond the specific conformance expectations of WCAG 2.0, Level AA are worth elaborating on, however!

Chapter 4, section 409: User Preferences. This section explicitly requires that applications allow users to set preferences for color, contrast, font type, size, and focus cursor. Thankfully, the rule is clearly written when it comes to development which is operated within a web browser: web browsers, as platforms which take some settings from an underlying platform, are expected to allow the underlying platform’s settings for these issues to take precedence.

To clarify this in simple terms: web browsers, or applications running within web browsers should not over-ride settings from the operating system.

Chapter 4, section 413: Authoring Tools. Essentially, this is an extension of the web authoring tool accessibility guidelines applied within Section 508. What it requires is that any tool which is used to author content or create documents — such as Microsoft Word, as a desktop application, or as WordPress, as a web-based content authoring tool — must allow the creation of accessible documents (such as by allowing the creation of alt attributes for images) and must not by default remove any accessibility feature — such as a video editing tool which would remove captions if editing a captioned video.

The section seems very reasonably written — it requires prompts for creating conforming documents, but also specifies that not every element should be prompted, as this can decrease usability.

Chapter 6, section 604, part 4: Real-Time Video. Live, streaming video must include real-time video description, with certain exceptions. This seems pretty explicit, and definitely is a valuable addition for people with disabilities. The exception provides for an exclusion for primarily visual and unattended situations. The example provided is a web camera overlooking a national park — it is purely visual, and there is little to no significant information to be gained from live video description.

Chapter 6, section 604, part 5: Multiple Visual Areas of Focus. When a video contains multiple areas of focus — such as a news program which also includes scrolling event notices beneath the main program — video description must be provided for all areas of focus. The provision suggests a couple of methods for accomplishing this, including divided audio tracks between left and right channels. It’s an interesting area to address. I can certainly see that this requirement can open up new areas of information availability to people with disabilities, but I can also see a number of potential problems in implementation. However, that is a question for another time!

Chapter 6, section 607: User Controls for Captions and Video Description. User controls must meet certain standards for accessibility functionality: in addition to the requirement that controls for closed captions or video description need to be present, they must also be present in the same context as other controls. It is not an acceptable option to hide controls for closed captions or video description in a corner — they should appear in contexts which have a similar prominence to other controls such as channel selection or volume adjustment.

Chapter 6, section 608: Audio Track and Volume Control. Essentially, media players must provide users an ability to isolate speech tracks and background sounds. This is obviously dependent on video production in order to function; as such, this section indicates that any videos produced must be produced with separate speech and background audio tracks, in addition to requiring that players must offer controls to separately adjust these tracks.

This clause seems to have some flaws to me — specifically, in the gross generality of “background audio” versus “speech.” Stating “speech” is very explicit, as it only refers to spoken text. However, in practical terms, there are actually three important bands of audio in synchonized media: background audio which is non-referential (music and some background sound effects), audio which is referential (some background sound effects: a knock at the door or other sound which is reacted to by the video), and speech. It can create a great deal of confusion to exclude those key sound effects from the speech track. The issue is closely related to issues with captioning and video description: it’s important to note certain sound events, since some conversations or events will lose meaning if the viewer is unaware of relevant background sounds.

On the whole, in my relatively brief examination of the updates to Section 508 standards, I’m happy with the results. Obviously, there’s always room for improvement — there’s still room for improvement in WCAG 2.0, which Section 508 could have changed — but I’d rather have a single set of base standards to reference than requirements which contradict each other! Working with standards isn’t the answer to every accessibility quandary, but you should never just ignore standards out of ignorance — instead, ignore them out of an educated disagreement.

Forthcoming Updates on Federal Section 508 Rules
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

Of course, the lack of support does have some consequences. We can’t just go out writing HTML 5 without having significant awareness of this lack of native support — we have to compensate.

Nonetheless, being able to incorporate great new elements like figure, progress, meter, nav to improve semantics or browser capabilities including content prefetching to provide a faster, more seamless experience for users is actually pretty exciting.

HTML5 Datetime input in Opera 10.53

But new input types…cold shivers.

Sadly, they’re also one of the less useful elements at the moment. Until support is available in browsers, they’ll simply fall back to a text field, unless supplemented by scripting to customize their behavior. But hey — easy upgrade, right?

From an accessibility perspective, this is fabulous news. Or rather, potentially fabulous news. These new input types — including date formats, time formats, numbers, ranges, and colors — are intended to provide user-friendly and accessibility-enabled interfaces for inputting these kinds of custom data. Ultimately, they’ll provide replacements (or fallbacks) to the innumerable JavaScripted widgets used to create date input or color selectors. Users, instead of encountering a different style of calendar every time they need to enter a date, could have a consistent user experience. Having the behavior built directly into the browser, and tied from there directly into any accessibility software in use offers a hugely more dependable experience for users of assistive technology.

Now, this all depends on several factors: vendor implementations need to meet user agent accessibility guidelines; interfaces between browsers need to be consistent; and, of course, the attribute values need to be implemented by enough browsers to make their use truly valuable!

Today, support is pretty limited. You can take a look at Roger Johansson’s HTML 5 input type test page and see whether your current browser supports any of them. If you’re using recent versions of Opera or Safari, the answer will be yes — otherwise, you won’t be seeing very much of interest for a while.

But you can implement these input types today.

All of these different input types fallback to a simple text input. If you’re using the HTML 5 doctype, there’s nothing stopping you from applying HTML 5 input types right now. Any browser that doesn’t support them will simply provide a field to enter plain text — so if you’re currently collecting email addresses in a text input (which seems pretty likely,) then you have no excuse not to change now. You may not see the benefits right away, but why wait? You’re not going to see any downsides, either.

Creating forms has long been a thorn in many a developer’s side. Dealing with how to best layout and collect date information, for example, is always a pain. Do you leave it as a simple text field, and have to deal with who-know-what kind of data received from the user? Do you use multiple select boxes, and force the user to walk through three or more fields just to enter the date? Do you use a JavaScript-based tool to provide a calendar, which may not have great accessibility, may behave strangely in some browsers, and may take a lot of development time to massage into providing the functionality you’re looking for?

Even when browser support for HTML 5 input types is fully available, it’s entirely possible that you’ll want to take the route to custom develop interfaces for various fields. However, unlike the past, you’ll only be needing to do this because something particularly unique is required for the project; for lower-budget projects, you can save a lot of labor and provide a solid interface just by using native features.

HTML 5 has cool stuff: new input types!
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

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">&nbsp;</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.

• Sensible Forms
• Pretty Accessible Forms
• Making Compact Forms more Accessible

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.

1. Educate. Teach the people who will be doing work on the site as much as you can – the what and the why.
2. 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.
3. 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.

When the right hand doesn’t listen to the left.
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

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!

Minimum Color Contrast Ratio Changed in WCAG 2
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

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

WCAG 2 Reaches Recommendation Status
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

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…

1. Check Headings
2. Check for Image Alternatives
3. Behavior without Javascript
4. Unique Page Titles
5. Check for Broken Links
6. URL Canonicalization
7. Robots Control
8. Download Times

1. Check for Headings

The use of appropriately coded HTML headings is important for both SEO and Accessibility. Headings should be used to define the content structure of the page, semantically demonstrating the importance of that text and providing additional in-page navigation tools for screen reader users.

Software required: Firefox Web Browser, FANGS Extension for Firefox.

What to do: After installing Fangs, navigate to the Tools menu in Firefox and select Fangs. Flip to the “Headings List” tab in Fangs. The output displayed in this list shows all of the headings on the current page and their heading levels. Sometimes you’ll see output with a number but no text — these are most likely headings which are using images within the heading element.

Which leads to the next point…

2. Check for Image Alternative Text

Providing alternative text attributes for your images is critical to accessibility. The logic behind how to provide alt attributes appropriately can be complicated, but the presence of the attribute itself is always necessary.

The quickest check for this problem is very simple: disable images in your browser.

Software required: Any browser.

What to do:

• Firefox: Tools » Options » Content » "Load Images Automatically" -- Unchecked
• Internet Explorer: Tools » Internet Options » Advanced » Scroll to "Multimedia" » "Show pictures" -- Unchecked
• Opera: Tools » Preferences » Web Pages » "Images" -- Select "No Images"
• Safari 3 for Windows: Although you can disable images, the browser does not automatically display alt attributes in their place.

The results will vary somewhat from browser to browser, but in general they’re fairly consistent. If an alt attribute is present and contains text, that text will be displayed in place of the image. Look at the text and decide whether it’s appropriate! If there is no alt attribute text, the image will be left as a blank space. If there is no alt attribute at all, however, the image will instead be replaced in some cases by the file name of the image, in others by a simple broken image icon. If the navigation button for “Purchase my Widgets” suddenly says “Nav_image_10x10_30.gif” then that’s really not useful.

3. Behavior without Javascript

The definitive key concern about Javascript is that search spiders browse the web without it. For accessibility, the issue is significantly more complex, but there can be no question that making sure that your site is usable without Javascript is a major concern for both concerns.

As with images, the simple test is to disable Javascript in your browser.

Software required: Any browser.

What to do:

• Firefox: Tools » Options » Content » "Enable Javascript" -- Unchecked
• Internet Explorer: Tools » Internet Options » Security » Scroll to "Scripting" » "Active Scripting" -- Disable
• Opera: Tools » Quick Preferences » "Enable Javascript" -- Unchecked"
• Safari 3 for Windows: Edit » Preferences » Security » "Enable Javascript" -- Unchecked

If there are problems, they should become immediately apparent. I’ve seen occasions where the entire content area vanished or the entire navigation menu suddenly disappeared. It may be more subtle, but the simple test is to look for key content which is no longer available to your browser.

4. Page Titles

A unique page title for every page of your site is a crucial part of best practices for both accessibility and SEO. It helps orient your visitors, and allows searchers to know what they’re coming to.

Test Page Titles (Simple version)

Software required: Any browser.

What to do: Look at the top of your browser window. Does it say something like “Untitled Document” or just read the URL of your site? You’ve probably got a problem. In order to really get anywhere with this, you need to check most pages of your site, so for larger sites, you may want a more thorough method.

Test Page Titles (Thorough version)

Software required: Xenu Link Sleuth or similar site spidering tool.

What to do: Install the software and run it. Navigate to the File menu and select “Check URL.” Enter the URL of your web site. Select “OK.” Wait. The tool will now spider your web site and generate a list of linked documents on your site. This will include all images, external links, etc., by default, although it can be configured differently.

One of the columns in the results is “Title.” If you sort the results by type (select the header of the column “Type”) such that text/html filters to the top, you’ll have a list of pages on your site. Simply scan down the “Title” column. Are they all the same, or are large numbers of pages the same? That’s a problem. Every page should have a unique title.

5. Broken Links

Don’t close Xenu yet — because it’ll also check for broken links. Re-sort the output by “Status.” Find the section with the status of “not found.” Any file which came up as not found is, simply stated, a broken link. Broken links can have a lot of consequences for your website — loss of trust, frustration for your visitors, or even causing an inability for visitors to get key information.

6. URL Canonicalization

URL Canonicalization is a big, fancy word which simply means that all possible variations on a page’s URL lead ultimately to the same URL.

The issue is simply that all of these URLs can be exactly the same page:

• http://www.yourdomain.com/index.php
• http://www.yourdomain.com/
• http://www.yourdomain.com/index.php?t=success&r=fail
• http://www.yourdomain.com/index.php?r=fail&t=success
• http://yourdomain.com/index.php
• http://yourdomain.com/
• http://yourdomain.com/index.php?t=success&r=fail
• http://yourdomain.com/index.php?r=fail&t=success

And it’s entirely probable there could be more. Now, checking for all variations can be a somewhat tedious task. However, the one big variation which is likely to apply to every page of your site is the “www” or no “www” conundrum. It really doesn’t matter which you choose as your preferred site — but you should absolutely choose just one.

Testing the behavior of your site with this problem is absurdly easy.

Software required: Any browser.

What to do: Go to your website. Place your cursor in the address bar of your browser and change the URL. If your site is currently displaying “http://www.yourdomain.com,” remove the “www.”. If it’s currently displaying “http://yourdomain.com,” add it in.

There are three basic possibilities for what will happen at this point:

1. The site will automatically redirect to the alternate version. If you change the address, hit return, and the URL immediately switches back to what it was before, then this is what has happened. This is the correct behavior, although from a technical standpoint you’ll also want to check that the right type of redirect has happened. (You want a 301 redirect.)
2. Nothing will happen. The site will reload identically with the new URL. This isn’t a total disaster, but it does mean that your site isn’t canonicalized — both versions of your URLs are available. You should investigate implementing URL canonicalization.
3. You’ll get a file not found or server error. This is bad. This may mean that your hosting service is not configured to send both versions of your URL to your account, although this isn’t the only explanation. You can’t ever assume that people will link to the correct version of your URL or check their links, so it’s very important that every possible variation will eventually arrive at the right destination!

7. Robots Control

Most of the time, robots control isn’t a critical part of your site. The various directives, either in meta elements on your web site pages or in a robots.txt file on your site are usually intended to prevent specific information from being indexed by search engine spiders. If it’s missing entirely, it’s not really the end of the world.

However, if you have a robots.txt problem, you have a serious problem. If you’ve accidentally set your robots.txt file or meta elements to block robots from crawling or indexing your pages, then you’re simply dead in the water.

This is somewhat of a multiple step process:

1. Enter your home page URL in your browser address bar like this: http://www.yourdomain.com/robots.txt. If you receive an error message, than the file simply isn’t there. You may wish to add one — to reduce the number of error messages in your server logs, if nothing else, but you can be pretty certain that you aren’t blocking search spiders with it.
2. If you do have a robots.txt file, you’ll see it displayed in your browser. It’s a very simple file format, consisting primarily of three types of statement: User-Agent, Disallow and Allow. By default, everything is allowed; so most robots.txt files only contain User-Agent and Disallow statements. This is the Disallow statement you really don’t want to see:

   User-Agent: *
   Disallow: /
   

   In simple terms, this says “No search spiders are allowed to access this site.” The single forward slash means that the statement refers to all directories on the site. The * means all user agents — which includes Google’s search spider, Yahoo’s search spider, and so on.

   A more common file will be something like this:

   User-Agent: *
   Disallow: /private/
   Disallow: /images/
   Disallow: /admin/
   

   This is more specifically disallowing three folders which the web site owner does not want available to the public.

   If you want to check specific URLs, or find that your robots.txt is quite complicated (they can be!) Google offers robots.txt checking tools in their webmaster tools. (Requires a Google account.)

That’s taken care of your robots.txt file; but what about more specific directions? Meta elements can provide instructions to robots as well, which operate on a page specific basis. These are much harder to check, since it requires a page by page check — and, frankly, there may be specific pages which you don’t want indexed. Regardless, this is what to look for:

Or variations on that theme. The code states that, for the current page, spiders should not index the information and should not follow links from the page. If you find this on a page which you’re having trouble getting in the search index: that’s the reason!

8. Check your Web site’s Download Time

The time it takes your site to download can have a huge impact on the likelihood a visitor will stick around. Although broadband is popular, it’s still just barely a majority of the internet market. Assuming that visitors will wait around to see that high-resolution image of your product is simply foolish.

It’s easy to check approximately how long it will take your site to load at a variety of download speeds. The actual download times for a given user will be hugely variable, since there are many more factors than raw bandwidth at play when accessing a web site — but this quick test will at least give you an idea.

Visit the web site optimization analyzer. This tool will give you the total anticipated download time at a variety of bandwidths, and also breaks down, file by file, the total size of the elements of your web page.

Even if you’re satisfied with the time required to download your site (8 seconds at 56k used to be the benchmark; although you need to make your own decision depending on your site’s needs,) you can use this information to streamline your site. Optimizing graphics and only loading scripts on pages which actually use them can make a huge difference.

Conclusion

Touching on these issues won’t clear up every problem you could have: but they can save you a lot of headaches. Fixing these issues will generally improve the overall condition of your web site in a variety of ways. You’ll end up in a better position to work on SEO and you’ll offer your visitors a more accessible web site.

It can’t hurt to check!

Web site Tune-up: 8 Quick Checkups
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

Use the Color Contrast Spectrum Tester or compare the contrast of two colors.

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. 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:

• #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 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.

Testing Color Contrast for WCAG 1 & 2
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

This is part 1 of 2. Part 2 is my Guide to the use of Semantic HTML Elements

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

Why use semantic HTML?
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design

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…

Using standards doesn’t make it right
Copyright 2004 – 2011 Joseph C Dolson, Accessible Web Design