Yes, that does say HTML 4 in the title. This is not an article about HTML 5, or, indeed, about anything which is at all new. But it’s not just new technology which needs discussion in the web development sphere!

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.

Some time ago, I ran across an interesting post on Clients from Hell:

Website user who couldn’t find an article emailed our help desk. We sent him the link to the content he couldn’t find.

Client: “Please change the letters in your email to blue, so I can click the link.”

Clients from Hell

While this was intended to ridicule a misunderstanding — that the client couldn’t click the link unless the letters were blue — it does stand to illustrate a real problem with usability. Even though there may be relatively few people who actually experience the exact problem above, there are undoubtedly many people who could fail to realize that text is a link when it doesn’t conform to their expectations.

It’s not just whether or not your links are blue — there’s also an issue with internal consistency. If you’ve made a decision that links will be something other than blue, people can learn that. But you may want to consider being internally consistent with that change — I’ve seen many web sites where different areas of the page change the coloration of links: sidebar links are gray, body links orange, footer links black, etc.

Regions of the page specifically dedicated to navigation can frequently get away with alternate appearances, but having a different link scheme all around the site is very likely to just confuse. Inconsistent coloration, inconsistent use of text underlining, or minimal hover or focus changes can all serve to reduce the usability of your web site in significant ways.

Do links need to be blue? No, not really. If you insist on always having links blue you’re going to limit your design options in more ways than are really likely to be beneficial. However, if blue links won’t compromise the design, there’s really no reason not to use them.

Keeping basic usability in mind at every stage of design is just a good idea — at least, if you’re going for a successful web site!

I’ve always believed that web site accessibility depends on an understanding of accessibility issues — not on technical issues. Obviously, knowing the technical side of web site construction and how it impacts accessibility is very important. Some decisions are fundamentally technical, but a huge part of web site accessibility is purely visible — and just understanding accessibility issues will make a huge difference.

To that end, here are a few quick comments about color blindness. Color blindness (or color perception deficiency) is an issue for approximately 1 in 12 people, mostly men. However, color perception problems are not always very effectively diagnosed, so these numbers could be low.

Color blindness is an inability to see certain colors.

Color blindness is really a misnomer. People with various types of color blindness are better described as being color vision deficient: it’s an inability to distinguish colors, not an inability to see color. People at the furthest limits of color deficiency, however, may have such an extreme inability to discern colors that this can be a fairly accurate description.

Individuals with color vision deficiencies can’t see red.

Well, no. Assuming we’re discussing Protanopic or Deuteranopic color blindness, in which the individual is missing either the red or green sensitive cones, the actual problem is that they may not be able to distinguish the color red. The color isn’t readily differentiated from other hues of the same shade or tint. Red perception deficiency is certainly the most common type of color vision deficiency, but it’s certainly not true of all individuals with poor color vision.

You have normal color vision

Not really. In fact, color perception is a spectrum for all of us. What’s commonly referred to as color blindness is actually only the portion of that spectrum which is considered anomalous — where the ability to perceive color begins to impinge on normal interactions with the world. Having “normal” color vision simply means that you don’t generally experience problems because of your color vision. You may well still fail an Ishihara test.

Color perception deficiencies are inconvenient, but don’t pose any serious problems

Particularly in our modern, technological society, color perception is a critical part of comprehending the world around you. From LED indicators which blink red, green, or yellow; to weather maps which a spectrum from red to green indicating storm severity; to knowing what color a traffic signal is showing if you’re in a location with a different signal orientation than what you’re familiar with. Outside of technology, color deficiencies can impact recognizing that you’re developing a severe sunburn or knowing whether you’ve actually cooked that hamburger enough to be safe.

People with Color Perception Deficiency have better Night Vision

Actually, I couldn’t definitely verify this one way or the other. There are a number of claims that this is true, but the reasoning is highly variable and not particularly evidence-based. It’s possible that certain types of color perception deficiency may give people better night vision, but it’s also possible that since some types of color perception deficiencies cause people to be photosensitive, those people may feel like their night vision is better, simply because it’s much better than what they’re accustomed to. Regardless, any evidence which is reasonably definitive would be appreciated.

Additional Resources

• Vision Simulator
• Colour Blindness on the Web isn’t a big deal

Whenever somebody tells me that they really don’t see the point in doing usability testing on their web site, I can’t help myself from asking why. Let’s be honest here — what’s a really good reason for skipping usability testing? The first thing that comes to my mind, of course, is because you’ve just finished a major usability review. I can understand wanting to give it a skip if you’ve just gone through the usability testing process!

But, surprisingly, that’s not the response I actually hear from people. Actually, the most common reasons are very simple:

1. I’ve never had a problem with it
2. Nobody’s every complained about a problem

Unfortunately, both of these justifications are problematic. They really aren’t a good reason for passing on usability. See, usability isn’t just about whether or not something worked; it’s also about what happens when a process doesn’t work out. It’s not about whether you made it through the process, it’s about how easy it is to make it through process. You’re pretty well guaranteed to be out of the running in testing your web site — because you actually know how your web site is supposed to work.

If you know that a field takes a particular data format – say, a five-digit postal code – then you’re going to tend to provide what you know the web site wants. It’s what happens when you don’t already know the system which is more educational.

This is certainly a frustrating aspect to usability – no arguments there. But you can’t escape it: if you have inside knowledge about a system, you’re just the wrong person to test it. Obviously, this means that problems that other users have are an important element to pay attention to.

However, a lack of reported problems is not at all the same as not having problems.

Nobody’s ever complained about a problem with your web site? That’s not a certainty of any sort. It could be a different kind of issue — rather than having problems which are very clear cut, such as an inability to enter an international address, you may be experiencing time-out frustrations or issues with a particular payment type being rejected. Or perhaps the problem is actually with the ability to report problems — maybe you haven’t provided an obvious means for people to contact you. Perhaps there’s actually a problem with your contact method itself — negative evidence is essentially worthless. All you can conclude from an absense of complaints is that nobody has delivered a complaint to you. You don’t know that they didn’t try, and you don’t know that they didn’t have a problem.

And finally, having a problem isn’t exactly what usability is trying to fix.

Your users may not be having any problems — they don’t have anything concrete to complain about. However, because your purchase process is onerous, a large percentage of those who begin the purchase fail to complete it. They may not have had an actual problem — they just decided that using your web site was too much work.

Maybe they’re just lazy — but if you’ve got lazy prospects, your site needs to work harder at keeping them around. Don’t let your web site slack off.

Well, it’s a day for updates. Today was (at one point) the deadline for Twitter to permanently disable Basic authentication. The date has now been extended to August 31st, but the difference isn’t really significant.

The one benefit which it will provide is a little extra time to debug the new OAuth version of WP to Twitter before it becomes the only working version.

There are a lot of complications surrounding the OAuth update — most of them unfortunate. For the first time since I began work on this plugin, I had to remove features. As far as I can tell, there’s no way to operate two separate user accounts with an OAuth authenticated application, for example. As a result, I’ve had to remove the ability to assign separate author accounts for Twitter posting. As development progresses, a way forward may show up — but for now, I just don’t really have another option.

My biggest request at this time: if you can, please decide you’re willing to use this version now, to provide me with feedback so it will work as well as it possibly can when all past versions cease to be functional.

There will be problems; I’m sure of it. I just hope to find them all soon enough.

Section 508 web accessibility standards were written as an amendment to the Rehabilitation Act in 1998. In web development terms, this isn’t short of an eternity — and in all practical sense defines an era. The web programming methods and styles of 1998 were radically different to what you see in normal use today. The Section 508 rules have been under revision recently, and were available for public comment until June 21, 2010. Unfortunately, my time didn’t allow me to take a look at these prior to the expiration of the public comment period — but that doesn’t lessen the importance of examining the revisions.

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.

Steve Faulkner, from The Paciello Group, just announced the beta release of their new Accessibility Viewer application aViewer. The purpose of the application is to give easy access to what information the browser is reporting back through Accessibility APIs. It’s an interesting application, and certainly has the potential to provide useful information in the future.

It is in beta, of course, so it may not function entirely perfectly — in my installation, I had trouble getting a few features to work properly. I couldn’t get the cursor view to do anything at all, for example, nor could I get the cursor tool to turn on using F5, as the documentation describes. The Code view only seemed to show the text values for links — and nothing elsewhere. (For reference, this is on Windows Vista using Firefox 3.6.3.)

Nonetheless, I can see the potential for this software as a helpful tool for exploring both the accessibility of an interface and the awareness of a browser concerning that information. It’s a good idea, and with feedback is likely to become a useful tool, as well!

Steve is asking for feedback, so be sure to install this in your environment and take a look.