l() does not accept a parameter for supplemental text for screen-readers

Fits nicely in with this discussion from the groups - http://groups.drupal.org/node/17627

Now that we're very close on a means to push the content off-screen it will be good to start providing a mechanism to provide fuller more meaningful links that allow sites to become WCAG 2.0 compliant.

Isn't enough to pass array('html' => TRUE) as value for the parameter $options, to be able to use HTML in the text passed to l()?

Try with l("Read more...<span class="visibility-invisible">about blog-post-name-here</span>", $url, array('html' => TRUE)).

The point is that there is already a way to do what you are suggesting to do using another option passed to l(). I am not sure the additional option you are suggesting will be added.

I tend to agree with Everett here.

But... is there a common word for what you're proposing we add here? "hidden link text" is not very semantic.

Does "Add options for semantic content to l()" sound better?

Rather than adding a further option to l() why don't we add a set of new functions?
if I want to make my page more semantic, it's more probable I will not need just l(), which is suggested to not be used together t() (the example in the documentation for t() suggests to use url()). There are many occasions where I could need to output semantic HTML, including in a menu callback.

Add tag.

Subscribe.

Everett, something that could maybe help in determining the direction is describing a few use cases in core in which we would use this, and a few more in which we would NOT use this. I think that could help us nail the syntax down. Also, pointers to existing high-profile sites that already are adding similar text to their navigation elements would be super helpful for reference as well.

Like Kiam, I do get kind of an ooky feeling from overloading a function intended for outputting just links to instead output links along with weird "special" text (along with its own "special" markup) that Drupal will spit out at random places. In addition to this breaking our degradation in browsers that don't support CSS or have it shut off, I think it also may cause problems for themers that randomly some links have these phantom invisible spans next to them and others don't.

Are we totally breaking new ground here? Are there no best practices from how other CMSes/Frameworks/etc. are dealing with this requirement? Do link title attributes not fulfill this requirement? Those are at least part of the XHTML spec, and l() already supports them.

It needs work. Probably the span should be a theme function. The text surely needs improvement.
But is just a starting point to have something "tangible" to talk about.

@Everett Zufelt
Using suffix or prefix wouldn't help. When you write a l function inside a module you don't know if it will be used on a LTR or RTL site. A possible solution is to check for the global language direction and place the text accordingly.

@tic2000: Why would prefix, suffix not work in RTL languages? Right now you have implemented a suffix, even though you haven't called it that.

Looking at this further, I think one of the biggest problems will be, that the entire string (with invisible and visible) will no longer be in context. If I setup a link in my module with separate strings for link, and accessible text, then those would be translated separately and may no longer make sense in context. Maybe some sort of replacement patterns similar to t would make sense.

Also, you should add this documentation to l() as well, since the options apply there as well.

BTW, can you roll your patches with -p option? It make it easier to read if one could tell which function is being patched.

It has to be easy, when appropriate, to add extra descriptive text for screenreaders. It shouldn't be needed very often compared to the number of places links are used that have sufficient contextual information. The best example I know of is the state of tabs as Everett mentioned earlier. The state information is visually conveyed by highlighting one of several tabs using CSS. Adding hidden text to the name on the tab performs the same function for a screenreader (with a side-effect of showing it to any user without CSS).

I'm a little concerned about using hidden text for the cases in #14.4. As a sighted user, I'd like to be able to perceive all the information on a "Read More..." link. Similarly, it's quite possible for a themer to overuse this technique for differentiating link text presented to a screenreader when there's a more usable design that would work for any user agent.

If the extra option is added to the l() function then it's important to be clear about where it's meant to be used, referring to the WCAG best practices.

The patch in #15 looks okay but shouldn't $accessibility be passed through check_plain() too?

I'm also not a fan of the name "accessibility" for the text, it's specifically meant for screenreaders and it'll be rendered hidden with CSS. Maybe $hidden_after (possibly along with "$hidden_before" in line with the suggestion in #16.2).

+1 for the patch in #15

It is important to get this in core and to document the best practices. Without this change, it is hard for Drupal sites to meet accessibility standards. We end up killing kittens or using tricky overrides. This change would encourage the whole Drupal community to add accessibility text into a link in a consistent, clean way.

Regarding prefix and suffix, I believe we only need a suffix, although it does no harm to provide both. It is my understanding of RTL languages that the order of content in the HTML source code is always in the same order -- the order in which it will be read or spoken by the sighted user or the screenreader -- regardless of its arrangement on screen. So I think we only need a suffix.

A prime use case is the "Read More" links (#49428). I understand that not everyone will want to use this capability in every situation, but that's why we should provide a standard way to do it in core and document the best practices.

@Brigadier, not to be snide, but as a sighted user, to perceive all information on the "Read more…" links being discussed, just glance at the <h2> for that post.

I hope all who are following this discussion are also aware of the recent posts in http://groups.drupal.org/node/17627, a related active discussion in http://groups.drupal.org/accessibility.

Just sayin'.

One problem I see with this approach is that (while I don't do much localization) I suppose it's rather bad form to concat translated strings together. Imagine the following examples from the node/add page:

(Text inside parenthesis is assumed to be invisible, but accessible text):

Link text: Page
Full text: (Create new) Page.

This example (verb-adjective-noun) works well in English, but may not work well languages with a verb-noun-adjective construct.

What I would propose, is a complete string be provided for the accessible text, with a placeholder similar to the t() function, for the link text. With that in mind, one might provide the following link text, and accessible text to the example above:

Link text: "Page"
Accessible text: "Create new %link_text"
Output: <a href=""><span class="element-invisible">Create new </span>Page</a>

Thoughts?

I don't think this is necessary at all.

l(t('Read more...<span class="visibility-invisible"> about %title</span>', array('%title' => $node->title)), 'node/' . $node->nid, array('html' => TRUE));

will work perfectly for that. The <span> is part of the sentence, we have to keep it in the same string for translation purposes.

The pattern itself is nice, and I would love to see this "additional information" added to a few links all around core.

And honestly is the only way so translations can work properly

@Everett: what about using this issue to add 'supplemental text' to a few links of core?

For example, we could start with the "selected tab" issue, except if you have a better idea.

Absolutely this should be documented better and encouraged more. Adding it here would help --> http://drupal.org/node/394094

Other than the read more links, which should probably be addressed on a theming level, are there priority modules where you'd like to see greater use of this hidden text?

There is a suggestion for use here
#510094: Add description to the link items of the toolbar
#49428: Include node title in "Read more" link for better accessibility and SEO

I added some documentation to the link above, but should be brought into core D7 theme & module docs. Where are those?