[MGNLSTK-263] Alt texts missing Created: 26/Jan/09  Updated: 19/Jul/12  Resolved: 26/Jun/12

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: None
Affects Version/s: 1.0
Fix Version/s: 2.0.4

Type: Bug Priority: Neutral
Reporter: Timo Wirth Assignee: Zdenek Skodik
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Issue Links:
supersession
is superseded by DOCU-287 Provide informations on how to set an... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

There is no possibility for editors to add an alt text. From accessibility perspective this very important Could we provide a field in the dialogue?



 Comments   
Comment by Boris Kraft [ 28/Jan/09 ]

I suggest to repurpose the "Subject" field, as the alt-text is exactly that - the subject of the image. I don't think we should add an alt-text field to the general DMS dialog

Comment by Philipp Bracher [ 29/Jan/09 ]

True.

But we need a solution for the images we upload directly to the paragraph.

Now that we have that scenario 'standardized' we should really think about having a image control which you can toggle (dms, upload, onair, ..). A simple image model bean could then be used in the templates:

  • better usability
  • simple templates
  • extendable
Comment by Federico Grilli [ 16/Apr/12 ]

Some background info on the alt attribute http://www.w3.org/QA/Tips/altAttribute

Comment by Boris Kraft [ 16/Apr/12 ]

In this case, the upload control should probably provide additional field(s) to substitute the missing info as otherwise retrieved from the DMS. Specifically the "alt" text field. To some extend it could be argued that an image already contains embedded meta data (in fact, tons of it in some cases, just check the Aperture meta data tabs). Magnolia – at least as an asset management - would need to be able to extract and write back such information.

Just remember: by adding additional fields to a dialog, we don't improve its ease-of-use. We need to be very clear what we do and why we do it. In this specific case on could argue that if you need alt texts, use the DMS. Still, I agree that an alt attribute is best practice so let's add one. In a text/image component we actually have a lot of meta data added already, like the Image Caption, Copyright and Description. These are in fact fields that should be part of the image's embedded meta data and retrieved from there (except for the caption which is clearly editorial).

In case of the T/I component I suggest to add an alt-field and use the Description field as a default in case nothing is entered in the alt field. It seems right now the "subheading" field is used as the alt tag, which makes little sense when a description field is present. Note that this change would need to be documented and communicated to current users.

Comment by Zdenek Skodik [ 11/Jun/12 ]

As per the T/I component, the alt value is resolved from the Image Caption at the moment, and if this field is not filled in, then it falls back to the Subheading field of the text tab, prefixed by an Image string. IMHO duplicating the Image Caption field with another brand new one does not bring much sense from the user perspective, perhaps we could only extend the chain to fall back to Description when no Caption is provided, otherwise take the Subheading as the very last option, as this field used to contain a value, and even if not, the hardcoded Image string injected at the moment ensures the alt tag will never be empty.

Comment by Zdenek Skodik [ 11/Jun/12 ]

The fact that STK uses an image macro for manipulating with any sort of such binaries ensures that the alt attribute is clearly defined in the same way for both the dms-link and upload approaches one can add an image to any page. From that point of view appending a new field directly to the upload control would introduce unnecessary dependency to the concept. Keeping things clear I'd not do nothing regarding this ticket (apart from adding the description field as a fall back value), if there is wider agreement on this.

Comment by Boris Kraft [ 11/Jun/12 ]

If the way alt text is derived from existing fields is clearly communicated to the editors, then that is fine. However, currently it is not.

Can you please document here the exact way that an alt attribute is rendered for both the upload and the DMS case?

Comment by Zdenek Skodik [ 11/Jun/12 ]

At the moment there is no single point of entry for any of these two controls, but it's always a matter of the script which sets the alt value accordingly. We have about 15 scripts doing so. In most cases a certain dialog field is used as the very first option, usually a title. On contrary the imageGallery inherits from DMS. If we're not going to change it, I'll document it closely.

Comment by Zdenek Skodik [ 12/Jun/12 ]

Every image tag provided by STK includes the alt attribute nowadays. Its value used to be configured on the editor side, via a various dialog fields, while there is also kept a default value as a fall back option. This practice can be followed also for any custom templates/components one could write. Thus we're not going to append the attribute to the involved controls directly, also because of it'd requite updating the STK scripts to take this value as the very first option, and that the controls are going to be rewritten for incoming Magnolia CMS 5.0 anyway.

Comment by Jan Haderka [ 25/Jun/12 ]

If we're not going to change it, I'll document it closely.

Related documentation issue is not linked. Is it already documented or are you going to document it?

Comment by Zdenek Skodik [ 26/Jun/12 ]

A documentation task was opened as DOCU-287. The list was attached to that ticket.

Comment by Jan Haderka [ 26/Jun/12 ]

Thx

Generated at Mon Feb 12 07:25:19 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.