Confusing image next to the title on Public Domain, Contact, History, Annual Reports, Strategic Plan, Opportunities, etc. at typical width

[Chealer]

Large images were recently added at the top of many pages. These are different on each page (although some are reused).

A mild example would be the “Stay up-to-date on commons news” page, which uses an image with 2 free photos. At a typical resolution (above 765 pixels of width), the image displays to the right of “Stay up-to-date on commons news”:

This is not confusing, since the heading is not an actual title, and even if it was, it would arguably be aligned with its contents (the left edges are aligned).

On most affected pages though, the layout is quite different, and the result is confusing. The worst example I found is the Public Domain page. There, the image is a coccinella. Although it follows the heading in the DOM, it is actually displayed first (left) at typical resolutions. Unlike in the previous case, in this case (and most cases):

1. The heading is an actual title, describing the page's topic.
2. The heading is shifted right.
3. The heading has 118 pixels of left padding, shifting it even more to the right.
4. The contents are very narrow (780 px).

The result of the latter 3 is that the title seems dissociated from its object, since horizontal alignment is lost. As the red borders I added in the following screenshot highlight, even the right edge is far from aligned:

Meanwhile, the vertical center matches the image’s vertical center; so the perception is that the title is a title for the image. But this is not the case. According to what @possumbilities indicated in ticket #1421, these images are just decorative. They do not illustrate the page, so any match with the title would be coincidental. And in this specific case, that perception is misleading, since the image is not in the public domain. This worsens confusion between CC licenses and the public domain.

When the viewport is less than 766 pixels wide, the top displays in DOM order, with the image below the title. In the specific case of the Public Domain page, having the image in the contents could still be misleading, but the risk is an order of magnitude smaller.

Other issues

Beyond confusion, these additions bring a few issues:

1. Much vertical space is used (even at 750 pixels width), pushing the start of the contents in the bottom half of the viewport, even on a Quad HD monitor.
2. The caption for the image used on a few pages is poor. Notably:

   1. The Contact page’s is captioned:

      Melies color Voyage dans la lune, by Georges Méliès, Public Domain.

      This seems to put part of the raw name of the file which appears to have been used, without its extension nor a link or any formatting clarifying it is a filename. Similar case for the Public Domain page.

   2. The Events page’s is captioned:

      "View of Street from a Glass Window" via Pixabay, here cropped, is marked with CC0. "Judith Beheading Holofernes" by Caravaggio and "Chakrasamvara with His Consort Vajravarahi," here cropped, are marked with CC0.

      But Judith Beheading Holofernes largely predates CC0 and was surely not offered under CC0.

3. Most images use an alt attribute. Most such img elements break the HTML, due to unescaped double quotes meant to be in the attribute’s value. For example:

   <img src="[https://creativecommons.org/wp-content/uploads/2026/04/events.png](view-source:https://creativecommons.org/wp-content/uploads/2026/04/events.png)" alt="Caravaggio's painting "Judith Beheading Holofernes," a blue photo of a rainy street, and a Tibetan painting of Chakrasamvara are layered with a bright-green "C" and a blue amorphous shape, in the style of Creative Common's visual brand." />

4. Accessibility to visually impaired users is not taken into account; screen readers will read the contents of the captions. Moreover, the alt attribute is not supposed to be used for decorative images; those which do cause screen readers (like NVDA) to read the similar description a second time.
5. Images are not served/encoded properly.
   1. For example, the Contact page and others use moon-3.jpg, a 1570 x 1194 pixels image which takes 431 kB, even though it is always squeezed to a maximum of 585 x 445 pixels.
   2. Most cases are unfortunately much worse. The image on the Events page has 2250 x 2500 pixels, and takes 5 MB because the composite is a PNG, which uses lossless compression, not designed for images with pictures. Even on a high-speed cable connection, the performance hit is clear.
6. The alt attribute on at least the Strategic Plan page is not just wrong, but misleading (visibly confused with another image):

   <img src="[https://creativecommons.org/wp-content/uploads/2026/04/Teams-1-1.png](view-source:https://creativecommons.org/wp-content/uploads/2026/04/Teams-1-1.png)" alt=""Flower" by Flower's.Lover, here cropped, is licensed with CC BY 2.0." />

7. The code is semantically incorrect, because the figures are in header elements not supposed to contain decorative images.

Solutions

At least most cases should surely be rolled back for the time being, but I for one find the image used for Strategic Plan (at least) beautiful, and there must be ways to integrate this properly. UI and accessibility are unfortunately far from my expertise, but I'd be glad to see people with experience in web integration and accessibility help reintroduce this with less rush.

Moving images to the right or using the whole width would mitigate or solve the confusion, but I suppose the best would be to move the images from the content to the background, as that page explains. This example shows the code which can be used, but is also designed to cover the whole viewport. It would be nice to display the images on the side when the viewport’s width suffices, pretty much like the bottom (newsletter) figure. That example shows a tiled background image, but that pattern is no longer common these days, and I am not finding an example of displaying just once fully on a side.

🅭🄍