[com_fields] Problem with Attributes TITLE and ALT in Media Field

[walturbo]

Steps to reproduce the issue

Creating a new custom media field does not require ALT and TITLE attributes

Expected result

Side frontend should display the ALT and TITLE attributes for SEO purposes

Actual result

Side frontend media does not have any ALT and TITLE attributes but only some manageable by css such as width and height

[brianteeman]

the ALT attribute is not for SEO it is for accessibility and is an essential requirement

[tarotray]

I researched this issue and I have come up with various solutions, from a quick & dirty one that merely solves the compliance issue to a vastly complex one that solves the entire issue to the satisfaction of the JAT team members - but would require almost a complete rewrite, in places. There are also in-between solutions.

There is no doubt that any move towards further accessibility in Joomla will require all images to have an alt attribute, at minimum. If the image has no significance to the end-user, it may have an empty alt text (i.e. alt="").

N.B. Further (but not dealt with here), the issue may not reside only within the custom fields feature, but also within image galleries and possible other Joomla features.

The simplest solution, requiring least code changes would be to add a line or two of code to the front-end rendering process, ensuring that, at minimum, an alt="" attribute is added to each image display for both the media field and the image list field. This would, at least, mean that standards compliance would be adhered to and automated testing tools would not flag an error.

@zwiastunsw has said that "Because when an image carries content, it must have alt text. The alternative text has to be decided by man and not by programme (computer)."

He also says "The alt attribute is for accessibility - for screen readers, for search engines, also for browsers when displaying images is disabled. It is supposed to transmit information instead of an image if the image adds new content to an article.
The title attribute is for people, it should meet the criteria of the title (short, interesting, significant). Repeating the title attribute in the alt attribute is always an error (the user of the screen reader hears the same thing twice).
The title attribute is optional, the alt attribute is mandatory. "

The complicated solution, favoured by some members of the JAT team, is to 1) add in sub-fields in the content editor interface, to allow the addition of both an alt text and a different title text, to be configured by the content developer. 2) This would be stored in the database as a) separate columns in the #__fields_values table, b) as a separate related table or c) as a change to the values of media fields and image list fields, to a comma-separated (or JSON) list of attributes.

As any variation of this latter would require a huge re-write, I would not recommend it but memebers of the JAT team feel that this would be essential. After all, currently, AFAICS no field has extra sub-fields included.

I draw the attention to @laoneo and ask for his comments.

[tarotray]

This is something like what I mean by "sub-fields in the content editor":

[RickR2H]

As a quick fix we could fill the alt text and title attribute by extracting the image name. For good SEO a descriptive name should be used. So this could be a useful way to start as isn't much work. I know people are going to be against it, but it is me being pragmatic.

[tarotray]

@RickR2H IMHO Using the file name is not a best solution. People use all sorts of strange file names, which make no sense to a screen reader. It would be better to have an empty alt text, which is acceptable, if the image has little significance.

[tarotray]

It seems that, in fact, a screen reader will read the file URL, if there is no alt text. If the alt text is empty, it will not. Therefore, if the developer is unable to determine the alt text, adding an empty one is the best solution.
https://www.w3.org/WAI/tutorials/images/decorative/

[RickR2H]

So adding an empty alt attribute must be added to the custom field output code? Shall I add a PR?

[brianteeman]

@RickR2H an empty alt is only acceptable if the image is purely for decorative purposes. It will mean that an automated a11y tester will pass but its not really a good option to apply everywhere. Better to come up with a real solution that allows the creation of real ALT text than to "cheat" the system

[RickR2H]

@brianteeman agree with you.

[tarotray]

I also agree but am aware that it would require quite some rewriting.

May I suggest that, if a developer can add an alt attribute, it would be sensible to also allow the addition of a title attribute.

Further, as it would not require much extra work, perhaps a link URL may also be a useful attribute to include.

[Bakual]

Imho, it would get very tricky if you want to set an alt or title attribute for the media field. You would have to get very "creative" (read: misuse the API) to make that possible.
Custom fields aren't designed to support this.

However, nothing stops you from creating additional custom fields so you have three custom fields like "media image", "media alt text" and "media title text". And then in your custom layout, you put those three together the way you need it.

[rytechsites]

We created an override for this, by setting the LABEL to work as the 'alt text', it isn't 'ideal', but it works...

`<?php
/**

• @Package Joomla.Plugin
• @subpackage Fields.Media
• @copyright Copyright (C) 2005 - 2018 Open Source Matters, Inc. All rights reserved.
• @license GNU General Public License version 2 or later; see LICENSE.txt
  */
  defined('_JEXEC') or die;

if ($field->value == '')
{
return;
}

$class = $fieldParams->get('image_class');

if ($class)
{
$class = ' class="' . htmlentities($class, ENT_COMPAT, 'UTF-8', true) . '"';
}

$value = (array) $field->value;
$buffer = '';

foreach ($value as $path)
{
if (!$path)
{
continue;
}
/* Added reference to alt using the field label */
$buffer .= sprintf('<img src="%s"%s alt="%s">',
htmlentities($path, ENT_COMPAT, 'UTF-8', true),
$class,
$field->label
);
}

echo $buffer;
`

[brianteeman]

This is essential and must be resolved. The work around by @radiant-tech is just a band aid etc which might be acceptable for joomla 3 it will not be for joomla 4 where we finally are taking accessibility seriously

[brianteeman]

Closed see #27571 for a single tracking issue