Need for Unique Strings for Different Links

In the Accessibility 101 class I've sat in on at Knowbility's John Slatin AccessU, among other conferences, that point is made very clear: One factor that goes into the mix of ranking a page in search results is the wording of links pointing to that page.

If 100 links pointing to your page say "Read more" and one says "Accessible Themes for Drupal," guess what Google will assume is on your page?

All other things being equal, to come out ahead of your page in Google searches for Drupal+themes+accessible, my page would need only two links pointing to it, so long as both said "Accessible Themes for Drupal."

In essence there is no reason why we cant do this now. Links are handled by each modules implementation of hook_link, so its just a matter of find all those in core, listing them and then getting to work writing the patches. Certainly I could do this however time is against me at this moment due to work in the theming track for D7 improvements.

I think we'd need to wrap node and comment titles (comments have links also) in a span and hide it to reduce visual clutter. I could write an example patch for node module (read more link) and use one of the proposed hide/remove classes on it.

Everett, Jim and I are on the WebAIM e-mail discussion list. In e-mails to that group, WebAIM's Jared Smith made it clear that the survey is not statistically valid, specifically because the data came only from people who learned of the survey and chose to participate. So there is no guarantee that the people who answered represent the full range of people who use assistive technology or even the full range of any particular subset of that group. It's in that sense than Jim means it's not a "good survey," and Jared would be the first to agree.

On the other hand, I think Jim would be the first to agree with us that the survey is valuable. For example, it led many accessibility specialists on both sides of the issue to reconsider their rules for "alt" text. Demands for "just the facts" softened on learning that sometimes the aesthetic experience matters to the person who is using assistive technology. Demands that "alt" text describe every detail of every image withered on learning how many people are annoyed by hearing more than just the facts.

When it comes to repeated link text in Drupal pages, I wonder: Haven't we made sure that each topic's title will be tagged with the appropriate heading level? (I'm asking because I know my memory is weak on this point.) If we have, doesn't that give people who rely on assistive technology a way to skip from topic to topic without having to listen to all the intervening links?

No one doubts that repeated links are annoying to anyone can't choose to avoid them, but let's be sure we are addressing problems that haven't been either solved or made irrelevant by other recent improvements.

Have we already done enough? If not, what functional problems remain?

Cliff

Everett, if we (and by "we" I mean "a lot of people other than Cliff," because I've done nothing but offer a thought now and then) have somehow built structure into these pages, then I don't think a usability test will tell us much. One interesting outcome of the WebAIM survey was how little many people who use JAWS or other assistive technology actually know about their software. (Jeez, you would think they were people who could see and were using Word or something!)

To some extent, the message I take from that is, "Don't rely on 'title' attributes to make a link destination clear." That would probably be the easiest thing to build in: Each "Read more..." link would have a unique 'title' attribute that identifies its destination. In principle, that solves the accessibility issue — except that almost nobody who uses JAWS knows that they can get it to read the 'title' attribute of links. And of the few I have met who do know how to make JAWS do that, none will use that feature regularly. (It isn't the most usable of the software's features.)

But to some extent, I also get the message, "Build structure into your pages, and trust that people who rely on assistive technology will learn how to use it to take advantage of that structure." The WebAIM survey tells me that a number of people who use screen readers don't know that yet — just as many, many people who use Word don't know the difference between (a) making a document look like it has headings and (b) making sure that Word, JAWS, Google, and everyone else who can't see knows that those particular words are that document's headings.

Because the WebAIM survey is not statistically valid, we can't be sure what percentage of folks who use screen readers know about and regularly use the features that reveal page structure. But I would guess that the people who knew about and participated in that survey know more than most about the features of their chosen assistive technology. And if a user test tells us that none of the users we tested know how to examine page structure with their software, for one thing, and how to exploit that knowledge to navigate smoothly through a well-structured page, for another, then what do we do?

It seems to me that the best answer is for those folks to learn more about their own software. They'll need that knowledge to navigate any electronic document. Shouldn't we trust that they will get that knowledge? After all, the alternative is to clutter up our page for everyone just to make things easier for those people who aren't taking advantage of the features of their own software.

And please understand that I'm saying this quite sympathetically, not at all critically. Most of what I do at work lately has been to teach people about all those features of Word that I alluded to above — the ones that make it more than a paperless typewriter.

@Everett, I agree wholeheartedly that we should not rely on title attributes to identify link destinations. Just to be sure we're being clear, the title attribute is one possible component of an anchor tag. In this not very elegant example, I've done a pretty crummy job of telling people where the link goes:

<a href="http://groups.drupal.org" title="All Drupal Groups">g.d.o</a>

because it's hard to get information from a title attribute, for one thing, and the value of title attributes is so variable that to rely on them for information would be an inefficient strategy for navigating the Web.

Instead, I'm pointing out that the items now coded as headings are easy for people using AT to get to and incredibly useful for locating specific chunks of content. In JAWS, pressing Insert-F6 takes you to a list of the headings on the page. At that point, to find the heading for the chapter or section that interests you is as easy as skimming a table of contents. When you have found that heading, it's easy to go to its portion of the page. And if you do that on the main Accessibility page, once you get to that part of the page, you have a well-defined unit that contains no systematically repeated link text. That's the key point: Find a heading and go to it. Then, before you encounter a second link reading "Read more," "Add new comment," or "Cliff," you would necessarily encounter another <h2>. That <h2> would be your clue that you're in a new section, so you should expect a new set of those systematic links to follow.

Unless you happen to know the actual text of a specific link on the page, using the list of headings is the most powerful way I know of to use JAWS to drill through content to the specific part you want. But the WebAIM survey revealed that people who use AT tend not to use that approach. When I examine the so-called "structure" of many current Web pages, I can see why: Headings aren't used enough and, when used, are often not used wisely enough to help people use them to grok (definition: get a sense of the overall organization of) the page. This page we are on right now is a good case in point:

• The main heading, "Need for Unique Strings for Different Links," is an <h1> (which is good, but from here we go downhill)
• The heading for each comment is an <h3> (which is not so good — we've skipped a level)
• The content of the headings for the various comments does not always help us tell what that comment is about — for example,
  • One deleted comment simply has an ellipsis for a heading
  • Another comment has a heading that JAWS would probably announce as "semicolon close parentheses"
  • One participant has a penchant for such uninformative headings as "Exactly," "Maybe," and "Don't shoot me, but …" (I wonder who that might be)
• Sometimes, headings are coded into comments — so we have something coded as an <h2> that actually should be subordinate to an <h3>, but of course no software can infer that relationship. (Tell me the text and the heading levels, and I would wonder why the <h2> "Mike" was the heading of a section containing the <h3>s "A more complicated way to simplify it," "Multiple windows is not an issue," "Fangs Emulator Rocks!," "Improved Fangs is more useful," and "Jaws Output." I would also wonder what concept could possibly tie all those <h3>s together.)

So I would hate to have to make sense of how the content of this page is organized simply from the structural cues embedded into it. In fact, I don't think I could. For example, should I read the heading of "Maybe" on one of my comments as a reply to the <h3> immediately preceding it, or was "Maybe" the second reply to some comment farther up the chain with all the <h3>s in between marking responses to the first response — or even to a response to the first response? So although the main page for a forum is in pretty good shape, the pages for individual discussions are not.

So what should we do? (Disclosure: As one who is guilty of mainly lobbing grenades into other people's plans for making improvements, I'm not among the "we" who "do" any of this.) Here's my suggestion:

• Chip away at the various types of Drupal pages to build into them structures as effective as those of our main forum pages.
• Add an "Accessibility Tips" link. (Bear with me.)
• At the destination of that link,
  • Tell what we have done to optimize the performance of Drupal pages with AT.
  • To the extent we can, suggest techniques that will let people who use AT take advantage of these built-in features.
  • Encourage them to do at least these two things:
    • If they still have problems grokking Drupal pages, join this forum to let people who might be able to fix those problems know that the problems exist.
    • To the extent that they find our approach effective, demand similar features in other Web sites they visit.

You know that old saying, "Give them a fish, you feed them for a day; teach them to fish, you feed them for a lifetime"? Well, the way I see it, if we were to do as I described above, we would be giving them a fish, teaching them to fish, and teaching them how to make other fisheries more productive. (Oh, and we would be giving Cliff something to do besides lob grenades: I could come up with the wording for the "Accessibility Tips" page.)

Am I dreaming, or does that make at least some sense?

Cliff