Mike Cherim and Jonathan Fenocchi, creators of the GrayBit service for showing a site design converted into grayscale, needed to move on. The time and expense of maintaining GrayBit was too much – and since Mike Cherim has moved out of the web development and accessibility world, it was necessary to make some changes. They recently shut down GrayBit.com, not having received any word that anybody wanted to take the site over.

I was too late to save the domain, which is now a travel magazine, but I have saved the service: GrayBit can now be found at http://gray-bit.com. I just did the move this morning, in about an hour, so there may be issues still to be seen – let me know if you encounter any problems!

For now, I’ve moved the service from being advertising supported to being donation supported; so, if you’re a supporter of GrayBit — please consider making a donation! I don’t know yet just what this service might end up costing me…

Jennifer Sutton brought this interesting factoid to my attention today: the single most common HTML validation error is the missing alt attribute.

Of the 100 most common validation errors collected by W3C Love, a missing alt attribute comes it at number one — with almost double the occurrences of the next most common error.

It’s 2012, and the key mistakes in HTML seem to remain the same.

Now, one can’t help but hope — since these are the results of validation tests — that these numbers also reflect a large number of people who went “Oh! Whoops! Better get that information in there.” Of course, some of those people may have then gone on to write in “Spacer.gif. 600 bytes. White line.” as their alt attribute.

Obviously, this raw number of errors doesn’t demonstrate a lot of definitive information. However, the mere fact that this is literally the most common validation the error points to some serious problems in HTML education or in HTML generating tools.

I can understand people providing bad text alternatives. When you read over the guidelines for authoring alt attributes — either in the HTML 5 specs or Steve Faulkner’s slightly-more-easily-understood Techniques for useful text alternatives, it’s easy to get overwhelmed. The chains of instructions: this MUST be done, that MAY be done, this is REQUIRED, that is OPTIONAL…it can be a lot to digest.

But omitting the alt attribute entirely is kind of scary. Yes, it’s true that the HTML5 spec currently (and unfortunately) allows the alt attribute to be excluded in certain very limited situations — but the statement that alt attribute is optional in HTML 5 is far from accurate. It is definitely still required, and omitting the attribute is discouraged in no uncertain terms, as below:

Such cases are to be kept to an absolute minimum. If there is even the slightest possibility of the author having the ability to provide real alternative text, then it would not be acceptable to omit the alt attribute.

Even the most casual search of phrases like “alt attribute optional” brings up many, many results clearly indicating the importance of using the alt attribute without even a suggestion that the attribute is in fact optional, so it seems like somebody would have to work pretty hard to come away with the impression that it was optional.

Why is it left out so frequently?

We need better education. Ignorance is still the primary guiding factor in casual web development. When people are exercising barely-learned skills, they tend to go in the direction of the simplest possible set of instructions — leaving out any portion which doesn’t seem to have any impact. That means that images are included with a src attribute; possibly with width and height; and frequently with some kind of inline style or border instruction. Alt attribute? Why?

Any time you read up on an alt attribute, you’re likely to run smack into the TL;DR problem: explaining how to use alt attributes in any detail means a long, involved explanation. Even explaining the incredible difference between an empty alt attribute and an ommitted alt attribute is over the head of many layman content authors.

We need better decision making tools. It’s necessary to simplify. The experts need to work out the complex details of what, why, how, and when an alt attribute should be one thing or another. For the layman, it needs to be summed up as simply as possible.

Here’s my idea of a generalized alt attribute decision tree:

• Is this image a link or form control?
  • Yes: Alt attribute must communicate the destination of the link or action taken
  • No: Continue on!
• Does this image contain text?
  • Yes: Alt attribute should include the communicative text of the image (not text included for visual effect)
  • No: Continue on!
• Does the image contribute meaning to the current page or context?
  • Yes, and it’s a simple graphic or photograph: the alt attribute should briefly describe the image in a way that conveys that meaning.
  • Yes, and it’s a graph or complex piece of information: the information contained in the image must be included elsewhere on the page.
  • No: the alt attribute should be empty.
• Is the image something other than the above?
  • The alt attribute should be empty.

This very definitely does not cover all cases. But it’s much better than nothing; I hope that somebody is able to make use of it. If you have a quarrel with the wording or instructions, let me know in the comments!

It is incredibly hard to resist covering more and more issues here. But the purpose of this decision tree is to provide a simple and understandable tool to navigate the most common circumstances. This is not the place to explain the entire scope of alternative content.

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.

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.

Even though many elements of HTML 5 have only limited application at this time due to lacking browser support, there’s little reason not to make use of them. The design of the markup language is intended to minimize dependence on user agents, failing invisibly if the browser doesn’t offer that feature, which helps encourage early use of new elements.

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.

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.

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!