Background

I recently played with a design idea which would show several lists of content each with its own feed.

I quickly realized that the theme_feed_icon() function only accepted the feed url giving me a page with several feed icons each saying "Syndicate content".

On a page with only one feed icon the text "Syndicate content" might be informative enough for users using screen readers given the context.

But on a page featuring several feed icons the user might loose the context due to other aspects the page layout.

I did a quick mod for the theme making the alt and title optionally modifiable. I later added the possibility to also change the path for the icon.

In the patch I have done the same for theme_xml_icon().

The patch

The patch only changes theme_feed_Icon() and theme_xml_icon() in includes/theme.inc.

The patch will not break current use of theme_feed_Icon() and theme_xml_icon() since behavior is the same as before when only given an url.

The patch is based on head:

// $Id: theme.inc,v 1.313 2006/08/30 07:37:13 drumm Exp $

Ideas for expanding this patch

  • Currently no feed link is created if the image is missing. Adding support for creating a text link as a fallback and adding parameters to both change the default text and force a text link.
  • Doxygen description of parameters.

Code snippet before/after the patch

Before:

function theme_feed_icon($url) {
  if ($image = theme('image', 'misc/feed.png', t('Syndicate content'), t('Syndicate content'))) {
    return '<a href="'. check_url($url) .'" class="feed-icon">'. $image. '</a>';
  }
}

After:

function theme_feed_icon($url, $alt = t('Syndicate content'), $title = t('Syndicate content'), $img = 'misc/feed.png') {
  if ($image = theme('image', check_url($img), check_plain($alt), check_plain($title))) {
    return '<a href="'. check_url($url) .'" class="feed-icon">'. $image. '</a>';
  }
}

Similar change for theme_xml_icon().

Comments

Tiburón’s picture

Getting some sleep before posting might have helped but there is an obvious syntax problem in the code sample which is also in the patch :-(

I did a quick test of the patch and it seemed to work alas I forgot about cache so when the cache had timed out the site broke with a syntax error.

I will fix the code and resubmit a working patch.

drumm’s picture

Status: Needs review » Needs work
lilou’s picture

Version: x.y.z » 7.x-dev

This feature request is it still valid ?

lilou’s picture

Title: More flexible theme_feed_icon() and theme_xml_icon() without breaking current behavior » More flexible theme_feed_icon() without breaking current behavior
mgifford’s picture

Issue tags: +Accessibility

possible accessibility issue.

Although from the /blog page there are these two instances:

From the Blog's RSS

<a href="/blog/feed" class="feed-icon"><img src="/misc/feed.png" alt="Syndicate content" title="RSS - blogs" width="16" height="16" /></a>

From the site's RSS

<a href="/rss.xml" class="feed-icon"><img src="/misc/feed.png" alt="Syndicate content" title="Syndicate" width="16" height="16" /></a>

I think I'd need another instance where it just says "Syndicate content". I do think this could benefit with a more in-depth description though.

Mike

mohammed76’s picture

hello. subscribing, I think this should be pushed ahead.

I have just checked with three screen readers, one of them read the title attribute while the other 2 read the alt atribute "syndicate content", which just doesn't describe the link enough. would be nice if the alt attribute be context sensitive.

thanks.

mgifford’s picture

Would be so nice if screen readers had a standard that they all complied with. So the problem here is that some screen readers read the alt tag of the image and others use the title tag, but it isn't consistent, so we need to push both forward with meaningful content.

Makes more sense now. +1

I think if governments invested a portion of what they do now into producing a cross platform, top of the line, open source screen reader that was based on open standards and had evaluation metrics for developers that we'd all be saving a lot of time & $$. That being said, don't see that happening any time soon.

Unfortunately, looks like the patch needs to be updated, 1 out of 1 hunk FAILED -- saving rejects to file includes/theme.inc.rej

mohammed76’s picture

hello again.

I asked the Mozilla accessibility
QA, Marco Zehe about what is prefered alt or title, or both, and he gave the following answer:

Generally, alt is preferred over title for images. For links, screen text is used in favor of the title attribute. So, if there is screen text, that becomes
the accessibleName, if title is present, too, it becomes the accessibleDescription.

The most important rule is that information should not be redundant. In other words, if for an image an alt is provided, there is generally no need to
put the same text into the title attribute. Firefox will ignore the title attribute's content if its text matches that of the alt attribute, or for links,
of the screen text.

So generally, title is useful if it provides *additional* information that the user can choose to read or not.

Mike, I definitely agree with you on the idea of an open source, top of the line screen reader. NVDA is an attempt to do this, and it already has come along way into a mature screen reader. By the way, developers can use this screen reader to have a feel of how their work will be presented by screen readers, and marco has written this excellent article to illustrate how.

hope that helps!

mgifford’s picture

Status: Needs work » Needs review
StatusFileSize
new1.9 KB

Thanks mohammed76,

You found an expert, so I'm rolling a patch to fix this.

Not sure about references to - http://drupal.org/node/172571

Other than that there's like a lot of duplicate code and we might be able to just pass one function to the other with an alternate image.

Didn't really want to make too many changes in one patch though. Testable here - http://drupal7.dev.openconcept.ca/blog

I also brought in the logic that you mentioned to hide a duplicate title.

Mike

mgifford’s picture

Status: Needs review » Fixed

This is in core now - http://drupal.org/node/172571

MIke

Status: Fixed » Closed (fixed)
Issue tags: -Accessibility

Automatically closed -- issue fixed for 2 weeks with no activity.