More on Image alt Requirement in HTML5

Nearly two weeks ago I wrote up a post outlining the W3C decision to no longer require the alt attribute on images in HTML5: Image alt Attributes Not Always Required in HTML5. I was genuinely surprised to see that was the most popular post on this blog and garnered the most re-tweets on Twitter I've ever had.

I pulled the alt decision off the W3C mailing list, before it was officially announced in any forum, so I suspected it might languish in obscurity for a while. I wasn't quite right. First, to recap the decision:

• The presence of aria-labelledby does not make missing alt conforming.
• The presence of role=presentation does not make missing alt conforming.
• The presence of <meta name=generator> makes missing alt conforming.
• Use of private communications does not, in itself, make missing alt conforming.
• The presence of title makes missing alt conforming.
• The presence of figcaption makes missing alt conforming.

Just over a week later, Steve Faulkner, member of W3C HTML Working Group along with other W3C working groups, provided a more in-depth and detailed overview, including a re-hash of the full decision in his post HTML5 Accessibility Chops: the alt decision.

On Friday, the HTML Accessibility Task Force mailing list took up the discussion of the alt attribute, starting in the email with the subject "[text] updated draft of clarification on alt validation." This message outlines the response to the alt decision, specifically targeting those issues with which the Accessibility Task Force has taken issue.

To distill the response on why the exception for the presence of <meta name=generator> should be re-examined (these are just the key points, descriptions of each are in the email):

• Evidence: deliberately omitting alt due to generator exception.
• Evidence: list of authoring tools (mis)using the meta generator.
• Evidence: lack of alt checking is harming:
  • A reintroduction of versioning.
  • Two tier document quality.
  • Generator is already in use for other purposes.
  • Drops all requirements on the floor.
  • Alternatives to the generator exception.

A distilled high-level list of why the presence of a title attribute obviates the need for an alt:

• Title has taken on the role of a visual element in the form of a tooltip and invisible when images are turned off, but alt is visible when images are turned off.
• Where images are disabled or inaccessible in current browsers such as smartphones saving bandwidth, title will be useless to users.
• Title text will now be generated on even decorative images, negatively impacting the user experience.
• A link to screenshots (IE8, Firefox, Chrome, Opera, Safari) is provided as an example of how a title and alt display when images are disabled.

Finally, on the decision that <figure> with an associated <figcaption> allows the exclusion of alt (also distilled):

• Given that <figcaption> lends itself to verbose text, this may be far more than is necessary for an end user, and removes the ability for the user to choose.
• Current use of <figcaption> tends to be for images users can see, whereas alt is for images users cannot see.
• Screen readers do not currently support <figcaption>, meaning it cannot effectively replace alt today.

Further discussion on this draft is scheduled for a meeting among the W3C HTML Accessibility Task Force today (May 2). In the meantime, feedback has been rolling in from other members on the list, some of them challenging the assertions made in the draft response. You can continue to follow the discussion by reading the thread in the April 2011 mail archive. Since May has just started and this thread crosses into May, you can catch up on the most recent discussion in the May 2011 mail archives.

Sadly, as evidenced by my posting silence for most of April, I won't be able to follow the results of a meeting today and will probably have to wait for the news like everyone else. If this topic interests you , then you may want to follow along on the W3C mailing list archives.

Image alt Attributes Not Always Required in HTML5

It has long been accepted that the alt attribute of the <img> element, while not a perfect method to provide a text alternative to an image, is still a necessary attribute to provide at least some level of access to the image content for users who cannot see the image (whether by disability or otherwise).

The alt attribute is required on images in HTML 4.01. The notion that the alt is a de facto required attribute in future versions of HTML is echoed in the WCAG version 1.0 and 2.0 (7.1 of WCAG 1.0, H67 and F38 of WCAG 2.0). It is even stated as much in the latest W3C HTML5 working draft document, HTML5: Techniques for providing useful text alternatives, as you can see in this sample conformance item:

When an image is decorative and it is the authors intent that it not convey any information, an empty alt attribute SHOULD be considered as an indication that the image can be safely ignored.

The W3C uses the strongest language in its arsenal when it says an alt should be used, even in this example of an empty attribute.

Yesterday the W3C mailing list rendered a decision on Issue-31 and Issue-80 (a combined issue). This issue was last reported by Ian Hickson of WHATWG on the W3C mailing list. Confusing though that may be, it's still a decision on the W3C list. The issue summary (not the decision):

Require that authors include alternative text for images. Provide detailed instructions and examples for doing so to all readers of the HTML specification.

The decision as outlined on the mailing list:

• The presence of aria-labelledby does not make missing alt conforming.
• The presence of role=presentation does not make missing alt conforming.
• The presence of <meta name=generator> makes missing alt conforming.
• Use of private communications does not, in itself, make missing alt conforming.
• The presence of title makes missing alt conforming.
• The presence of figcaption makes missing alt conforming.

Essentially, if you use a title attribute on your image, or wrap it in a <figure> with an associated <figcaption>, then you may exclude the alt attribute. In addition, the presence of a <meta name=generator> element, which implies the HTML was generated by some sort of WYSIWYG editor or automated tool, also makes the absence of an alt attribute valid.

There are arguments on both side of the issue, and the decision handed down on the mailing list does a good job of collecting them, even if the qualification of each may be cause for dissent. Given that the W3C is pushing HTML5 to Last Call status next month, it's unlikely this will change.

Warning: Opinion

An alt attribute is intended to describe the image to which it is affixed, but the (redundant) title attribute has been implemented by authors to provide more value to users owing to browsers typically rendering it as a tool-tip. While this doesn't preclude an author from inserting an alt as well, it also may result in use of solely the title when it may not offer a sufficient description of the image.

The argument for excluding alt in the presence of a <figure> and associated <figcaption> element applies best when the browser supports those elements. In time they will, but given the collection of users still on IE6, older assistive technologies, and the lack of understanding of these new elements, this leaves a gap for some users. This isn't a clean transition with a guarantee of the same level of accessibility as outlined in the current HTML 4.01 specification and accompanying WCAG versions.

I do not agree with letting an HTML page off the hook simply because it has been generated by an automatic tool of some sort (relying on the <meta name=generator> block of code). This is really included to allow generated HTML5 to validate, not because the tools are incapable of inserting a blank attribute value (though they may not have been coded to do so). The argument against this references the current lack of support for ATAG guidelines within HTML editors and generators. I think this caters to ego by allowing authors to claim validation that would otherwise fail.

In the end, I think the best approach (at least for web developers and authors) is to still require it in all cases, reducing the need for seasoned web developers to retrain themselves. Ideally, these web developers would still continue to include alt attributes in all cases. Developers of HTML editors/generators (who care about the output) will hopefully follow suit instead of inserting additional complexity at the risk of misunderstanding (and mis-coding) these new rules. Makers of HTML editors/generators that cannot implement the spec should not be given a free pass.

If you're really interested in <img> attributes on the chopping block, read up on the fun regarding longdesc at longdesc in HTML5.

Update: April 27, 2011

Steve Faulkner, member of W3C HTML Working Group along with other W3C working groups, provides a more in-depth and detailed overview, including a re-hash of the full decision in his post HTML5 Accessibility Chops: the alt decision.

Making and Using QR Codes (at evolt.org)

Having spent a good deal of time answering questions about QR codes lately, I figured the easiest thing to do for everyone was just write an article. And so I did. It went live very early this morning at evolt.org. Go check it out: Making and Using QR Codes.

If you aren't familiar with QR codes, they are those pixelated-looking collections of black and white squares that have been popping up more and more in recent weeks and months, even though they have existed for years. The QR (Quick Response) code was first developed in 1994 in Japan to track vehicle parts but has since grown to become a handy way to encode all sorts of data, most notably web site addresses for use in traditional media campaigns.

In the article I outline the general process of using QR codes in your own projects by providing suggestions on encoding web page addresses, how to build the QR code itself, and basic pre-press tips. I also push some other ideas, such as embedding on your printed web pages or embroidering into your headgear.

So again, go read Making and Using QR Codes at evolt.org and consider my year-old QR code primer, Real World Hyperlinks.

Color Has a Gray Pallor

Color is the newest social media application on the block, launched just after SxSW and relying on proximity-based media sharing instead of a friend model. Founded by names from other successful ventures along with $41 million in funding, Color seemed poised to storm the social media market.

One day after its launch, Color Labs, Inc. released an update to the Color app. Originally launched to support a 100 foot radius to find people for sharing, its new update was released to adjust that radius on the fly based on nearby activity. Considering the app is essentially useless without others who participate, this update is necessary to gain users (and necessary given it missed a great geek-dense SxSW event). When you read the opening statement in the product description in the Apple App Store and Android Marketplace, you can see that this need for others using the app nearby isn't exactly a surprise for Color:

WARNING: DON'T USE COLOR ALONE.

With so little activity visible to a user, users might look to the interface to provide some clues to using the app. After all, knowing if you are even using it correctly can manage your expectations one way or the other. Once installed, the app immediately asks for your first name, then prompts you for a photo of yourself, and then drops you right into its interface with some inexplicable icons (notwithstanding the tiny "Next" text-link-like buttons that move you along in the process). With no activity, it's hard to know what those icons do. This company-provided screen shot shows the app with its confounding icons in an ideally-active stream of content:

You might be motivated to look for a help screen in the application, but you'll have no luck. You might even be motivated to go to the Color web site to look for a tutorial or some form of documentation, but no luck. It turns out that there is a demo video available on Vimeo, but Color doesn't even link it from the site — you have to find it somewhere in the copious industry press coverage, which is something the typical user won't be doing.

When the Color Labs CEO says that the company is much more of a research company and a data mining company than a photo sharing site, it seems fair to question if the technology led the product rather than a tangible business model taking the lead. Given Color's reception so far, that seems like it may very well be the case.

In the Apple App Store product page for Color, the highest rated review of the product is really a parody, comparing it to a puzzle game (images of the full description):

You conquered Myst. You understood the end of Lost. You can do this! You're not going to let this new adventure game genre get the best of you! You will master this if it takes all weekend. You discover a button to create a group! You wonder what a group is. Progress, of sorts.

Given how easy it is to spoof GPS locations on a phone, even though the Color Labs CEO says that Color doesn't rely on GPS, it's a matter of time before a method to spoof locations is widespread. Let's not forget that Color is essentially anonymous, too, requiring no validation beyond location. It won't be long before you can expect to see Color turn into nothing more than a spam outlet or Chatroulette variant. I can assure you, I would not be letting my children (non-existent though they may be) install this app on their phones.

Related

• Color's Ambitious Photo App Seeks to Reinvent Mobile Social Networking
• Color CEO: The Tech Justifies the $41 Million
• Color to Get Major Update, Fix 'Loneliness' Problem
• PR Case Study: Where Color Went Wrong
• Color: Is it just the latest useless social media app?
• GPS check-ins taking off

Selection Bias When Reviewing Browser Stats

A recurring problem I find is when web developers, their support teams and their managers try to evaluate who is using their site(s) by reviewing their web logs (or Google Analytics) in a vacuum. It is far too easy to simply look at statistics reporting what browsers use a site to determine what browsers should be supported as new work is done. Unfortunately, this rarely takes into account how well the current site works with current browsers.

If your site, for example, uses features that are unique to a particular browser, you can expect to see that browser rank higher in your reports. This isn't necessarily because the browser is the preferred browser of your audience, but because users on different browsers either don't or can't use the site and either go away (perhaps never to return) or return to the site in a different browser (which may not be their default/preferred browser).

This is essentially a selection bias when reviewing browser stats, effectively funneling a particular type of user (or browser) to the top of your reports, reinforcing a preset opinion or conclusion.

This is a mistake we all make for various reasons. For example, the 3rd Annual State of Web Development Survey was announced on March 10 by John Allsop. He's no slouch in the web development world, even having built a tool for editing CSS. But the survey site that gathers information from web developers has its own selection bias — it is unusable in Internet Explorer 8. The CSS for the site is trying so hard to use CSS3 features (that look pretty swell in, say, Chrome) that visiting the site in Internet Explorer 8 produces white text inside white form fields with white text on light gray buttons.

In Chrome, however, the CSS3 effects make for some nice highlighting that helps indicate where I am as I go from field to field:

The survey asks what my default browser is, but to even get to that question I had to drop out of Internet Explorer and re-open the survey in Chrome. Web developers on the whole may not use Internet Explorer as their default browser (I do because it's what my clients use and I want to see the web as they do), so Web Directions can expect a relatively low number of users to report IE. If Web Directions and John Allsop review the logs/reports to see what browsers people actually use, they can expect to see a far lower number of users filling out the survey in Internet Explorer 8 than claim to use it as their default browser (because they cannot complete the survey). I am hoping that they are all smart enough not to draw a conclusion from that disparity (perhaps that respondents are lying), although I have seen people make that mistake time and time again. To be safe, I did tweet them to let them know (no response yet).

Some developers, however, make a decision that blocks browsers without understanding the impact. It's one thing for a site to display a message telling users to upgrade (see the latest incarnation, Microsoft Promoting the Death of IE6), but it's a whole other issue when you actively block users of certain browsers (example images below). It's easy to justify to your client/employer that nobody uses that browser when you show the reports, especially if the client/employer does not use the browser and you have provided inaccurate data to bolster your points.

I've seen this many times in my career, but recently ran into it with a local not-for-profit whose web developers had convinced it that Internet Explorer 6 and 7 not only weren't widely used, but when faced with the fact that many users are restricted to those browsers at work, was told that end users shouldn't — and for the most part don't — surf from work due to corporate policies. Asking to back that assertion up with a report of activity on the site by time of day was met with silence.

This is a selection bias of the worst kind, one driven by personal goals and agendas and ignoring data to the contrary while refusing to acknowledge those who provide contrary data. As a web developer, the example of the Web Directions survey is unfortunate, but most likely just a mistake. In this latter example there is no excuse and it is your responsibility as a developer to provide a better level of service not only to your clients, but particularly to your users.

Examples

The site blocking Internet Explorer 6 and 7 users.

Yet the site works for users of Lynx.

Spoofing the IE6 user agent string to use the site.

Microsoft Promoting the Death of IE6

That map above shows, as of February 28, 2011, the level of Internet Explorer 6 usage around the world. What's interesting is that this map was produced by Microsoft. This map is also (stolen by me) from a Microsoft site that is trying to move people off Internet Explorer 6, ostensibly on to Internet Explorer 8 or 9.

The site ie6countdown.com was unknown to me until today when I discovered it thanks to a tweet from @IE (Microsoft's Internet Explorer account) promoting it:

Interestingly, perhaps only to me, this tweet is exactly one year later than the surprisingly highly-publicized IE6 funeral (it supposedly died on March 1): RIP IE6 (Not Really, But Here's to Hoping). That people want to see IE6 go away is hardly news. You can read some of the history of companies and applications dropping support for IE6 by following the "IE6 must die" tag on Mashable articles. Sites like the obviously-named ie6nomore.com and ie6death.com have been pushing for these even longer. In fact, you can trace the history of the call for the demise of IE6 to the first breaths of IE7, sooner if you were a web developer.

While Microsoft is certainly hoping people will stop using IE6, and while the rest of us hope that people will also stop using IE7 (at least), there are still many users who have little or no choice in the matter. So many organizations built internal applications that rely on IE6 that upgrading the browser company-wide has a huge cost impact in everything from re-writing their applications to spikes in help desk requests. That employees cannot surf their local community not-for-profit site that inexplicably blocks IE6/7 is of little concern to IT managers.

What offends me about th ie6countdown site is how it promotes the use of an IE conditional comment to tell IE6 users to upgrade, something that may validate the existing terrible practice many developers have of trying to push users to the developer's favorite browser. However, since it only affects IE6 users and may help them take the necessary steps to upgrade, it has merit. Whether it makes their IT departments do so is another story.

Before you get too self-congratulatory about how much you used to despise IE6, take a look at this contextual view of IE6 back when it first launched, written by a Microsoft staffer: Presenting IE6 with the Lifetime Achievement Award. The title may seem a little too much like he's freebasing the Kool-Aid, but there is some good content presented in the context of 2001, including a screen shot of Netscape 6, my preferred browser at the time. If you want more history, go read Microsoft's history of Internet Explorer (I wish they would include the add-on to Microsoft Word that let you surf from the comfort of your word processor).

Much as I'd love to segue into the upcoming IE9 and where it stands, I'd rather this post solely be yet another (and hopefully last) memorial for IE6. That and I have to get to a meeting...

Update: 2:51pm

I came back from my meeting to find that Microsoft has a blog post about this very topic (announcements put it 2 minutes after my blog post): Counting Down Internet Explorer 6 Usage Share. In the post Microsoft acknowledges the IE6 funeral, talks about the olden days of IE6, and promotes the demise of IE6 — at least down to 1% market share. There is one statement for which I wish they had provided a link:

We know that many IE6 users are on the older browser because it's at their workplace. We've put together some resources for IT pros to help understand the business value of moving off IE6 and are delivering to them the tools to help them navigate the process.

A link to those resources would have been handy. Microsoft should take advantage of anyone reading its post who might need those links by allowing them to get to those resources immediately.

Later in the same post is a link to theie6countdown.com. Note the addition of "the" to the address. Apparently both work and answer separately at each address. Microsoft is costing its plan for the end of IE6 some valuable link juice.

Update: March 5, 2011

Bruce Lawson asks a very good question in the post The mystery of Microsoft IE6countdown.com — why can't Microsoft just make IE9 run on Windows XP, the most used OS in the world, instead of requiring users to upgrade to Windows 7 or Vista? Bruce points out that his employer, Opera, can do it. However, IE9 leans on features baked into the OS and Microsoft would much rather have you upgrade to the new OS anyway. My understanding is that Safari is the same on Mac. I know I have been unable to upgrade to the latest Safari on our older OSX machine without first upgrading to the latest feline version.

Recent(ish) News on Google, Bing, SEO/SEM

I have written many times here about SEO/SEM and how so much of it is sold to organizations by scam artists (though I recoil at the thought of calling them "artists"). Too often it includes demonstrably false claims, like how meta keywords and descriptions will help your site and that you should invest in the SEO vendor to do just that.

I also try hard not to spend too much time addressing the ever-changing landscape of the search engines, let alone focusing on just one of them. However, sometimes it's worth wrapping up some of the more interesting developments because they can genuinely affect my clients who aren't trying to game the search engines.

Content Farms and Site Scrapers

If you've spent any time searching through Google you may notice that sometimes you get multiple results on your search phrase that look the same in the results, but when visiting the site you find they are just ad-laden monstrosities with no value. Sometimes one of these spam sites would appear higher in the Google search results than the site from which the content was stolen.

Google has now taken steps to not only push those sites back down to the bowels where they belong, but also to penalize those sites. These changes started in late January and went through some more revisions at the end of last month.

I think it's fair to expect Google to keep tweaking these rules. Given all the sites that offer RSS feeds of their content (along with other syndication methods), it's likely that many sites integrate content from external sites into their own. The trick here will be for Google to recognize a site that has a original content that also syndicates third-party content from a site that has nothing but content taken from elsewhere. If you do syndicate content, then you should be sure to what you site stats and your ranking in the search results to see if you are affected at all.

Additional reading:

• Finding more high-quality sites in search
• Google Changes Algorithm To Penalize Site Scrapers
• Do You Republish Other People's Content? You'll Want to Read This
• Google Declares War on Content Farms
• Google Announces Massive Algorithm Change, Declares War On Content Farms, Including Demand Media

Page Titles

Perhaps you have spent a great deal of time carefully crafting your page titles (specifically the text that appears in the title and which displays in your browser title bar). Perhaps you have noticed that in Google the title you entered is not what appears on the search results page. This isn't a bug, doesn't mean your site was indexed improperly, and doesn't necessarily mean your page title had some other affect on your page rank. This is done intentionally by Google.

This does imply, however, that your titles are unwieldy. Google does this when titles are too short, when they used repeatedly throughout a site, or when they are stuffed with keywords. If you find that your title is being cut off (implying it's too long) then you may want to limit your title to 66 characters, or at least put the most important information in those first 66 characters.

Additional reading:

• Dynamic Title Snippets on SERPs
• When Google Rewrites Your Title Tags
• When Google Titles Don't Match Page Title

Social Media

It wasn't that long ago that Google and Bing said that links in social media (think Facebook and Twitter) will affect a site's position in search results (PageRank for Google). Some people may even be tempted to run out and post links to every social media outlet they can find, hoping that the more inbound links, the better for their site. Thankfully it's not that simple.

Both Google and Bing look at the social standing of a user when calculating the value of an inbound link. This can include number of followers (fans/friends on Facebook), number followed, what other content is posted, how much a user gets retweeted or mentioned and a few other factors. In short, those Twitter accounts that come and go in a matter of hours that tweet a thousand links into the ether aren't doing any good. A good social media strategy that is garnering success, however, should also give a boost to the sites it links.

What is not clear, however, is how URL shorteners (and which ones) affect the weight of those links.

Additional reading:

• What Social Signals Do Google & Bing Really Count?
• The Straight Dope on Facebook, Twitter, and SEO
• Google + Bing Confirm that Twitter/Facebook Influence SEO

Random Bits

These are some random articles I collected for posts that never happened. I still think there's good stuff in these and warrant a few minutes to read.

Google: Bing Is Cheating, Copying Our Search Results and Bing: Why Google's Wrong In Its Accusations should be read together. The accusation from Google that Bing is stealing its search results is fascinating on its own, but reading Bing's response demonstrates a host of things Bing also does differently. For me it was an entertaining battle, but that's about it.

HuffPo's Achilles Heel discusses how Huffington Post relies on questionable SEO techniques, which I equate to spamming, and wonders how long the site will be viable if AOL isn't willing to keep up the SEO game as the rules change. It could be a great purchase for AOL, or a dead site full of brief article stubs.

Is SEO Dead? 1997 Prediction, Meet 2009 Reality is a two-year-old article dealing with a twelve-year-old argument. And still relevant.

When A Stranger Calls: The Effect Of Agency Pitches On In-House SEO Programs should be particularly interesting to people who are charged with some form of SEO within an organization. Too often the unsolicited call or email comes in making grandiose promises and citing questionable data and results. This article provides a good position from which to push back and make sure you and your employer aren't taken to the cleaners.

A 3-Step SEO Copywriting Confession almost sounds like an admission of wrongdoing, but instead talks about how to structure your content for SEO without completely destroying it.

Additional reading (that I wrote):

• Negative Reviews Can Now Affect Site Rank Downward
• Your Site Speed to Affect Its Google Rank
• Verified: Google Ignores Meta Keywords