[OJS 3] Cover image: captions


several of our customers do not only want the “alternate text” for images, but also:

  1. Captions
  2. Text that appears when the mouse moves over the picture (title attribute)

Currently, as a workaround, we use the “alternate text” field.
We use it for license information and display that under the images, which is a bad solution.

I think additional fields for captions and the title attribute would be very useful.
Are there others who want that too? I couldn’t find it on the roadmap.
Maybe it’s easy to solve as a plugin, but then you’d have to change the templates too I guess.
Maybe it would be of general interest?

Best Regards

1 Like

Hi @ohilbig01,

Can you indicate which specific version of OJS you are using (e.g. 3.3.0-3) ?

PKP Team

Hi @rcgillis,

at the moment we are still using OJS
We are planning to upgrade to OJS

Hi @ohilbig01,

Interesting. I’ve done a little test of how this is handled in OJS 3.3. I think if this were to change, it would likely be added to 3.3 or a future version. So, when I go to add a cover image under the “Issue data” (this is where you are adding your cover images, correct?). It shows as having the option to add the alternative text:

Screen Shot 2021-05-07 at 6.38.01 AM

But, once you add the image, you no longer have the ability to add the alt text (only to change the file):

Screen Shot 2021-05-07 at 6.38.24 AM

But, then, if I save and go back, I then see the ability to enter/change the Alternative text alongside the image:

Screen Shot 2021-05-07 at 6.43.57 AM

I can then see that my image has loaded and, indeed the alt text is showing up (and presumably if the image wasn’t rendering the alt text would display.

Screen Shot 2021-05-07 at 6.47.17 AM

The issue of having the text display when mousing over an image is a browser specific characteristic: Why an HTML image alt text doesn't show on hover - the alt text would display on a mouseover, only in certain browsers. But, if for other browsers the image did not render, then the alt text would display.

The alt text isn’t really suitable for displaying license information - perhaps you can give us an example of what license information you display, and I can give some suggestions for how to go about this.

I’m also curious about your desire for captions - can you elaborate more details on what you’d like to see for captions and how you (or other users) might use them?

If you’d like to see how this works in OJS 3.3 - we do have demo versions that you can test it out, since you haven’t upgraded yet: https://pkp.sfu.ca/ojs/ojs_demo/

PKP Team

Hi @ohilbig01,

One further thing that I’ll note, is that there is also the ability to have an image appear for a section. It has similar capabilities - just the alternative text. Here’s an example from our demo instance:

Screen Shot 2021-05-07 at 7.05.38 AM

PKP Team

Hi @rcgillis ,

thanks for your answer. I know how the alt-attribute works.

What we would like to have is a data field in the backend containing the (cover image) caption. I’m not sure but I think OJS 2 had this feature.
By caption I mean a short sentence below the image that should contain license information. Something like “Copyright: John Doe” or “Source: pixabay”.
I don’t think the alt attribute should be used for this.

And the other thing would be another text field intended for a more descriptive text like “This is John sitting in his armchair. It is an antique chair from the 18th centurty and …bla…bla…”. Hm, this seems to be the definition of the “alternate text”, but it’s too long.

What we need is a longer descriptive text to be displayed using the HTML image title attribute, or using CSS hover. I could use the alternate text and write something like this in the Template:

<img src="blablabla" alt="{$coverImage.altText}" title="{$coverImage.altText}" >

The problem is, we have a journal which wishes to have two different texts, a short one (alt=…) and a longer one (title=…) . Maybe this request is too special.

Hi @ohilbig01,

Thanks for clarifying. I agree that the alt attribute isn’t suitable for the type of description that you describe (e.g. giving credit, etc.). I also agree that that such a field would be useful because it is often necessary to give credit for the use of photos that are displayed publicly, and at present, there really isn’t a way to do this. I also had a look at how OJS 2 handled this. Here’s an example:

Screen Shot 2021-05-07 at 10.42.46 AM

The cover caption displays pretty prominently, and there is also the alt text. I’m not sure what guided the decision to remove the caption - I suspect that it was taken out as the refactoring between OJS 2 and OJS3, but I’m not sure. I think it would really useful to have the caption.

I’m flagging my colleague @NateWr here, as he may wish to weigh in on this, and whether such fields ought to be (re)introduced.

Best regards,

PKP Team

Hi @rcgillis ,

this is an example of my workaround, using the alternate text:
Screenshot from 2021-05-10 09-32-03

A new text field for the mouseover text would also be very nice.

Best regards

Hi @ohilbig01,

Interesting - could you elaborate how you got that to displayed?

PKP Team

Hi @ohilbig01,

Thanks, I think it’s a good idea for us to try to support captions wherever possible. We may be more likely to add them to the article landing page rather than the issue table of contents, but a caption can be an important source of information like copyright/licensing.

I’m on the fence about the title tag. Information in the title tag is not available to visitors using assistive technology such as screen readers. I think it’s great that your editorial team is willing to carefully curate the alt and title tags to be different, but I suspect it’s unusual to see this attention to detail. And I’m worried that offering an alternative to the alt tag (which editors can’t see) may discourage its use in favor of title (which editors can see).

Hi @rcgillis,

I just used the alternate text, for example in article_summary.tpl:

    {if $publication->getLocalizedData('coverImage')}
            <div class="cover">
                    <a {if $journal}href="{url journal=$journal->getPath() page="article" op="view" path=$articlePath}"{else}href="{url page="article" op="view" path=$articlePath}"{/if} class="file">
                            {assign var="coverImage" value=$article->getCurrentPublication()->getLocalizedData('coverImage')}
                    </a><div class="pictureCopyright">{$article->getLocalizedCoverImageAltText()}</div>
    .pictureCopyright {
            font-size: @font-sml;
            font-weight: @normal;
            color: @text-light;
            float: left;
1 Like

HI @NateWr,

I understand your worries about the title tag, I’m a bit skeptical myself, but we have editors who want this.

The thing with the caption is pretty essential, because at least in germany you always have to indicate the image rights. I am convinced it would be useful for almost every uploaded picture, except it’s a logo or something.

Best regards

Thanks @ohilbig01 for this issue. We also miss the cover caption in OJS 3, it’s an essential feature to display the copyright.



An SFU journal has also requested an option to add a caption / attribution to images uploaded in the journal, including homepage images, issue cover images, article cover images, etc.

I’ve added a vote to this feature as I think it’s an important one in ensuring correct attribution for different kinds of content displayed in OJS. Our use case (which is exactly what @NateWr described above) is that images used for title pages and articles may have a different license or creator than the main article content, as this kind of content is often pulled from external sources like image collections. For example, an image used for a cover may have an “all rights reserved, copyright [creator]” license, or may require attribution and a link to a specific CC license as part of its terms for reuse. Articles published in the journal may have a different license, and the attribution would be for the author rather than the image creator. Captions would be very helpful in cases where the licenses don’t match up, or where attribution of the creator is required. This is a legal requirement for reuse in many cases, so editors will make not-so-great decisions about using workarounds like the altText field to house this info if there are no other options available.