Access Matters

Hidden text can be a spammer’s haven.

Years ago, when screen readers were at release 4.0, they started to change and actually pay attention to display:none. I ran a series of tests back then and knew exactly how every screen reader behaved. I was one of the earliest advocates of hiding helpful text off to the left of the visible viewport. I’ve used it cautiously for things like skip links, for the real text associated with image replacement headers, and for occassional other situations where the blind could benefit from having text available that wasn’t part of the visual design.

Along the way, people speculated whether search engine owners would eventually scoff at the technique. It is too similar to the nefarious methods of “link stuffing” that many spammers practice. I ignored the issue … until yesterday when I received the following from Google:

Dear site owner or webmaster of access-matters.com,

While we were indexing your webpages, we detected that some of your pages were using techniques that were outside our quality guidelines, which can be found here: http://www.google.com/webmasters/guidelines.html

In order to preserve the quality of our search engine, we have temporarily removed some webpages from our search results. Currently pages from access-matters.com are scheduled to be removed for at least 30 days.

Specifically, we detected the following practices on your webpages:

* The following hidden text on access-matters.com:

e.g.

cation approval card credit instant Low apr interest credit cards Juniper credit card application. Lowest phentermine prices Credit score Apply for a fleet low interest credit card application Zithromax no prescription Zoloft interactions Credit credit card applications? Hoodia information Propecia effectiveness, Reporting and interpreting liabilities Credit scores explained! Zocor lipitor Side effects from fosamax medicati

[…]

Ah gee, has it gotten so bad that they have to crack down on my very simple use of “off left?” Didn’t they look to see that the class is “access,” making it clear that it’s done for accessibility? So, it was off to their guidelines documents, and to their forums. The guidelines were not specific enough to answer my questions. The forums had lots of discussion, but most was speculation by curious people like me … and no answers from anyone with Google credentials. The best information I found was an interview with Google’s Matt Cutts at the StoneTemple Consulting site. In that interview, Matt said:

So, our philosophy has tried to be not to find any false positives, but to try to detect stuff that would qualify as keyword stuffing, or gibberish, or stitching pages, or scraping, especially put together with hidden text.

We use a combination of algorithmic and manual things to find hidden text.

There was little to lead me to believe they had cracked down hard. Yet, I was skeptical that they might no longer be doing the “manual things” and making due consideration. So, lets’ have a look…

I pulled up the site and disabled CSS using Chris Pederick’s excellent Web-Developer toolbar. ARRRRRRRRRRRRRRGHHHH! Just below the header area was a huge block of spam links. What the ??? Where the H___ did they come from?

Long story short, the site had been hacked. The hacker left behind one line of code in the header.php file. That line started with <font style=’position: absolute;overflow: hidden;height: 0;width: 0′> and contained about 150 links for various pharmaceutical products, doubtful financial products, and enhancement products of all types for all genders. Yes, the hosting service confirmed the password thefts. Yes, I cleaned it up and changed my passwords.

Yes, Google was right. Spam was stuffed into hidden text on my site.

They were not complaining about my accessibility technique.

The post just previous to this one is dated Jan 22. What you don’t see is “2007.” That’s right 15 months ago. What happened to cause blogging to subside?

In January 2007, I changed jobs. No, it was not to a different employer, but my sixth or seventh unique job at the same employer, IBM. While I hade been doing accessibility work for a number of years, it was a secondary part of my work. That changed in January 2007 when I moved to IBM’s Human Ability and Accessibility Center.

Hurray! Full time accessibility work.

Well, … yes and no. There are pros and cons to everything. On the plus side, my primary work was assisting our Human Resources division with improving the accessibility characteristics of the applications they sponsor. Many are custom built by outside firms with specific areas of expertise (investment counseling, health care services, career guidance, etc.), and all of these applications are used on our intranet by upwards of 380,000 IBM employees. That audience has the typcical distribution of disabilities, and making these applications fully accessible was both very important and highly appreciated. That part of the job was very satisfying.

On the other hand, I had been eligible for retirement for many years already, and the lure of other activites was growing stronger day by day. Travel, visiting grandchildren, woodworking, boat building, and various forms of artwork were all singing their siren songs.

I gave into the temptations and retired from IBM at the end of 2007, after 41 years of amazing technological progress. Accessibility is still a very strong interest, but not likely one that will be associated with “employment” any time soon. Four months into it, I find that retirement suits me well. — April 2008

This posting ends up being like previous quiz questions, but I’m dropping the old numbering sheme (related to WCAG principles) and the multiple choice answers as well. New year, new topics, time to move on.

I want to ask about a proposed technique, but first the set up.

A short while ago, Gez Lemon and Steve Faulkner published a very good article about how screen readers behave and some ideas on Making Ajax Work with Screen Readers. If you haven’t read it yet, it’s well worth the read. … Now, I’ll wait.

So, they’re back again with another. This time, they’re trying to lessen the burden on the visitors who use screen readers. Why put the onus on them to constantly shift modes if there’s something programatic that can be done? In Improving Ajax applications for JAWS users, Gez and Steve reveal a technique they have found which forces JAWS 7.1 to update its virtual buffer without user intervention.

I should trust that they are right in saying it’s new to JAWS and probably does little for other assistive technology products. Yet, as much trust and resect I have for these guys, you never know when a JAWS competitor might implement the same trigger. Plus, I’m curious to actually try it with a variety of assistive technology and browsers, more than I have at my own disposal.

That’s where you come in. I have two very simple test cases for you to try. The first is as simple an AJAX application as one can write. (Actually, I liberated it from Brothercake’s Sitepoint article AJAX and Screenreaders: When can it work?) The test case has one link which does one AJAX call and updates a paragraph. You can’t make one any simpler. The second test case simply extends the first with Gez and Steve’s updateBuffer technique. Go give each of them a quick try with whatever array of assistive technologies and browsers you have. Tell us how they behave.

• Simple AJAX Test Case 1
• Simple AJAX Test Case 1a

This test builds upon Simple AJAX Test #1 by extending it with a “hacK” to better support screen readers. It uses Gez Lemon and Steve Faulkner’s updateBuffer technique as published in their article “Improving AJAX applications for JAWS users.” Is it only for JAWS, or will it make a difference for others too?

This link is the trigger.

This paragraph will update with the response

What happens in your screen reader? Does it update and speak the response with no problems, or do you have to do something special to hear the response? Important: How does it compare with the behavior of Simple AJAX Test #1? When leaving a comment, please tell us which screen reader and browser you are using. Remember to include version numbers.

This is an incredibly simple AJAX test case. The link triggers an XMLHttpRequest which fetches a simple line of text from the server and updates this page.

This link is the trigger.

This paragraph will update with the response.

What happens in your screen reader? Does it update and speak the response with no problems, or do you have to do something special to hear the response? When leaving a comment, please tell us which screen reader and browser you are using. Remember to include version numbers.