Document how to set logo in theme with proper alt tags

By default the alt attribute assigned to the logo image (whether the image is the default theme logo or a custom logo) is the site name.

To clarify, that's only true in Garland. Stark uses "Home" as the logo's alt text.

I think for an interim measure, we can consider this a bug to be fixed:

- all core themes should have the same alt attribute for the logo
- this should be something more descriptive such as 'logo for $sitename' or '$sitename logo'. (see #787634: Site title is read three times with VoiceOver in Garland. for more background on this)

Let's get this fixed, and then move the provision of a custom alt attribute to D8.

So you're looking to add something like this to the system_theme_settings() function of modules/system/system.admin.inc?

     $form['logo']['settings']['logo_alt_text'] = array(
       '#type' => 'textfield',
       '#title' => t('Alternative text for to custom logo'),
       '#default_value' => $logo_alt_text,
       '#description' => t('A description of the custom logo if it conveys meaning. Otherwise it will assume the site name.'),
     );

I added it to line 544 and attached a screenshot for review.

Can this be brought into D7 using the Accessible Helper Module?

The solution in #5 looks good. Then we would make a 1-line change in Garland page.tpl.php and other themes to apply that ALT attribute.

Hello,
Still not in core. Should be I think. It's good for accessibility.

We discussed this at the DrupalCon London Accessibility BoF - http://groups.drupal.org/node/168744/

I did some work towards this for a D6 module which I never brought to full project status. I'll dig it out as a sandbox project.

@Everett
Sure. I'll try to get around to it soon. Still catching with stuff after DC and other travel.

That would be great Andrew, thanks!

I just took a quick look at the patch & had some questions about $site_name_and_slogan

Could this be used to populate the alt text by default when setting up the page?

It is certainly something that we have to get into D8.

Hi,

As mentioned at the London BoF, here is my earlier attempt at implementing this as a D6 module. As far as I can recall, it was in a working state. If you want to try it out, there's a modified version of Stark which included, with the necessary page.tpl.php changes. There are quite a lot of @todo comments, but hopefully you can see where I was going.

Being a module, it's a bit more verbose than the patch, with a hook_form_alter()

It's called logo_attributes, as I was considering use cases for other attributes like the logo' link @title, or even @rel=[start|contents]. (These use-cases are out of scope for this issue.)

@17: Yes, I also wondered about offering site name and slogan as options. (They are commented out in my module.) These could be relevant even if using the logo image provided by the theme. This use case was intended to cover the scenario where the logo was set to display, but the site slogan and site name were not.

Supporting tokens could be another option.

Re: comment 22

Point 1:
This is not the case. If $logo_alt_text is a template variable, then it can be altered by any module/theme which implements hook_preprocess_page(), and changed to whatever the developer/themer chooses.

There's also no reason why we couldn't offer the $site_name (and/or slogan) as an option in the theme settings form. So it could be a choice of:

• Use the Site Name
• Use the Site Name and Slogan
• Use the alternative text provided by the theme
• Use custom alternative text

This sort-of echoes the current options for the logo and favicon images, with the main difference that we probably don't not want to offer a 'none' value for $logo_alt_text.

I don't necessarily think that all of these options should be in core; extra use-cases could be handled by contrib modules. It would require little more than hook_form_alter() and hook_preprocess_page().

Point 2:
I agree that's a problem, but in a wider context than $logo_alt_text. String localization in themes could be a powerful feature in general. It's worth raising this with the localization and configuration folks.

Re: comment #15

So, if someone adds a custom logo with custom alt text, then goes back to using the default logo provided by the theme the alt text stays custom.

Is it necessary to couple the custom alt text to the custom logo option? Are there any use-cases for choosing the logo provided by the theme, but overriding the theme-provided alt text with custom alt text?

Use of $site_name could be one. Another would a workaround to translate the theme-provided alt text.

Re: comment 6

I'd be happy to do some more work towards a D7 version of this, either as a sub-module for the accessible helper project, or as a separate project. The momentum for getting this in core has rekindled my enthusiasm for a contrib module :-)

One problem, as I see it, is that my D6 module in #18 doesn't work out-of-the-box;. It requires a change to page.tpl.php

So if a site-builder has the logo_alt module enabled, and uses a theme from drupal.org contrib, they'll hit a brick-wall WTF unless they know how to change the page template. The best we can really do is provide thorough set-up documentation and/or raise awareness of the feature.

Having said that, I appreciate that the accessible helper modules goals include serving as a demonstration.

I'm doing the #d5dChallenge, so I spent time on this today.

After a bit of messing around, I came up with an approach for the problem in comment #15, keeping it all in theme_get_setting(). We can treat it more like the way the favicon path is generated. Store logo_custom_alt_text from the form, the test toggle_logo and default_logo to decide whether to return the custom text from the form, the default text from the theme, or Home.

My code needs a tidy, so I'll aim to post a patch tomorrow evening.

Another patch. Here's my take on things.

re-rolled patch, minor changes from comment 28.

Needs testing with settings provided by base themes.
Also I'd like to know what people think of the UI strings.

The UI strings look good to me.

When specifying a Logo alternative text source and saving the form, the option gets shown as Site name when finished instead of what was chosen.

Creating a custom alt text and saving the form replaces the alt text correctly in the theme. Editing a theme's .info file to set a custom alt text and choosing Default alternative text provided by the theme, however, does not get applied correctly in the theme.

+++ b/includes/theme.inc
@@ -1148,6 +1148,8 @@ function theme_get_setting($setting_name, $theme = NULL) {
+      'logo_alt_custom_text'             =>  '',
       'default_favicon'                  =>  1,

@@ -1177,6 +1179,13 @@ function theme_get_setting($setting_name, $theme = NULL) {
+        if (!empty($themes[$theme_key]->info['settings']['logo_alt_text'])) {

can it either use logo_alt_text or logo_alt_custom_text

2 days to next Drupal core point release.

#31: logo-custom-alt-717708-31.patch queued for re-testing.

I could use some clarification about logo_alt_text & logo_alt_custom_text too.

@andrewmacpherson this was introduced in the patch in #31 but would be good to have a bit more clarification on how it's used.

Why not use theme_image()?

#31: logo-custom-alt-717708-31.patch queued for re-testing.

This issue hasn't received consensus. Will re-open if someone wants to submit a new patch for review. It's a difficult use case where it is difficult to find where there is a good use case.

Where do you think the method for providing alt/title text needs to be documented? I'm assuming that the functions that were updated in this issue were documented properly in the API documentation, so probably you mean that some on-line Community Documentation pages need to be updated?

If so, the best thing to do is probably to either edit them directly, or leave this issue open in the Theme system component with status "needs work" and tag "needs documentation" until that is done.

The patch doesn't include any API documentation yet.

The logo_alt_custom_text setting was silly idea (just to get it working). Really it should just be logo_alt_text.

I recall having trouble with the internals of theme_get_setting(). Due to the way it sets up an array of theme settings, a custom alt text would end up over-writing the text from a theme (or base theme). I tried a few ways, and none of them were pretty. It might be a good candidate for the clean-up initiative.

I'll try to find time to re-roll this soon. The current patch is from the days before /core directory anyways.

In that case, I am moving this to the Documentation issue queue.

I can't recall if we'd decided that this issue here was also a won't fix - #1270598: Decide on appropriate alt text for default logo - would be good to either fix it or mark it closed.

Updated summary

There's no code to review, just documentation to write.

I created documentation over in Drupal theming, https://drupal.org/node/2281499. Does that resolve this issue?

I think it is, thanks! We may open it up in the future, but our decision the last time we looked at it was to deal with it in documentation rather than code.

wrong closed status.