If there is no<a> wrapper, the image cannot be opened

[otary]

<div id="test3">
            <img class="img2"
                 src="https://img2.baidu.com/it/u=3329909248,3799019568&fm=253&fmt=auto&app=138&f=JPEG?w=889&h=500"
            />
            <img class="img2"
                 src="https://img2.baidu.com/it/u=3329909248,3799019568&fm=253&fmt=auto&app=138&f=JPEG?w=889&h=500"
            />
            <img class="img2"
                 src="https://img2.baidu.com/it/u=3329909248,3799019568&fm=253&fmt=auto&app=138&f=JPEG?w=889&h=500"
            />
 </div>

const photoSwipeLightbox = new PhotoSwipeLightbox({
                 gallery: '#test3',
                children: '.img2',
                pswpModule: () => PhotoSwipe
});
photoSwipeLightbox.init();

As shown above, clicking on the image can open it, but it cannot display the image！

I don't want to add wrapper, is there any way to achieve the goal??

[arnowelzel]

Without an wrapper there is nothing to click on and users won't expect that clicking an element which is not a link to something or a button element will do something. Especially since the mouse pointer won't indicate this as well. You may need to build a collection of all images first yourself and add a click handler for each image which will then call the respective method in PhotoSwipe to open a lightbox for the specific image.

[KnIfER]

you can bypass the "A"===t.tagName check inside of photoswipe.umd.min.js and photoswipe-lightbox.umd.min.js

[arnowelzel]

And by the way - it is not the visible images which are displayed in the lightbox it is the the links. The visible images should just be smaller thumbnails and not the final images.

Usually the final images displayed in the lightbox are much bigger then what you see on the website.

See here for example: https://wordpress-demo.arnowelzel.de/lightbox-with-photoswipe-5/

[Anton-Evstigneev]

Such tight coupling with anchor tag results in bad UX when user tries to click on image while page's still loading. So instead of opening zoom overlay, user is navigated away from the site to an empty page with just one image.

[arnowelzel]

About the "bad UX" comment: when the user clicks on an image before the loading process has finished, the script is not loaded yet. That's the reason why the browser will show the image instead of opening the lightbox. But I would like to see your alternative how it should be handled instead. Any live example? Also keep in mind, that event handlers need to be added to the images for PhotoSwipe. I'd like to learn how to do this while the document is still loading and the DOM is not built completely yet.

And in general - maybe there is misunderstanding how image galleries on websites work. Except a very few execptions, the images which are visible in the website are not the ones which are displayed in the lightbox.

So the usual pattern is:

<a href="full-resolution-image.jpg"><img src="preview-image.jpg" alt="alternative text" /></a>

Also keep in mind the semantic here: the anchor tells the browser "here is something the user can open". This is important! By adding an anchor, the browser will also display a different pointer when hovering with the mouse and makes the element focusable. When the user is not able to use a mouse but navigates by switchting from one focusable element to the next, this is also important: an image itself is not focusable - only anchors with a reference and input elements are.

Also keep in mind: how to distinguish between images which are just decorative and others which are intended to be clicked by the user? This is also indicated by adding an anchor element - as an indication "this image links to something you can open".

In my opinion I would close this issue as "won't fix" since the way how PhotoSwipe works is the logical and expected behaviour: only those images will be used for the lightbox which would be opened anyway when them, even without JavaScript and PhotoSwipe. If you want to have a custom solution, you still can create your own frontend script which adds all images to a collection and pass that to PhotoSwipe and add event handlers to the collected images. You can also generate the script code in the backend and pass that along with "onclick" handlers hardcoded in the image tags.

[tennox]

I also would prefer to be able to do something like this:

<div class="gallery-image cursor-pointer" role="button">
  <img ... >
</div>

(role=button docs)

...but I get your point with using a semantic tag like <a>, so here is a way to address the

bad UX when user tries to click on image while page's still loading

<a href="javascript:void(0);" data-pwsp-src="imageUrl">

this makes the link just do nothing when gallery code is not loaded yet

[arnowelzel]

...but I get your point with using a semantic tag like <a>, so here is a way to address the

bad UX when user tries to click on image while page's still loading

<a href="javascript:void(0);" data-pwsp-src="imageUrl">

this makes the link just do nothing when gallery code is not loaded yet

Yes, this could solve the issue that images can be clicked before the DOM is completely loaded.

But I am not sure if this is "good UX" since it creates a new problem: If JavaScript is disabled - maybe because the user does not want this for security reasons or there are security policies which forbid JavaScript by default - image links don't work at all.

What you describe as "bad UX" is just the fact, that images may not be opened in the PhotoSwipe lightbox if a user clicks too early. However images will be opened in any case, even if there is no JavaScript at all - either in a lightbox or as a single image. This is still better than keeping everybody from opening an image if there is no JavaScript available. Yes, having JavaScript avialable is expected nowadays, but good web design should always keep graceful degradation in mind which is a very important thing for accessibility too.

I also doubt, that handling the consequences of slow loading websites is something which should be addressed in PhotoSwipe. If a website takes significantly longer than a few seconds to load under normal conditions (which means at least 10 MBit/s downstream which should be the baseline for most users), then there a more serious issues that should be fixed in the server side.

Edit:

If you don't want the user to click anything at all before the DOM is completely loaded, you may also add some additional layer on top of it which get's all click events and remove that layer in a script when the DOM is ready. However, this would also prevent anyone from using the website if no JavaScript is available.

In addition - anchors fire "onlick" events when you use the keyboard to navigate, elements with the "button" role seem to behave different:

<p><a href="#" onclick="alert('link 1 was clicked!')">Focusable link</a></p>

<div role="button" tabindex="0" onclick="alert('DIV was clicked!')">
Click me!
</div>

<p><a href="#" onclick="alert('link 2 was clicked!')">Second focusable link</a><p>

The two links can be opened by navigating the focus with the keyboard and then using the enter key. However this is not possible with the DIV element - eventhough you can click it.

[Andrew-web-coder]

Interestingly, Fancybox works fine without a wrapping element - https://jsfiddle.net/hdp70a6m/

[arnowelzel]

Yes, you can capture clicks on every element! But this does not mean, that this is a good idea.

IMG elements without an A wrapper around it can not be focused and therefore this is not barrier free!

[tennox]

IMG elements without an A wrapper around it can not be focused and therefore this is not barrier free!

How about setting tabindex ?

[arnowelzel]

tabindex would work indeed. But then you have exactly the same behaviour as before - and this makes no sense. And tabindex is also not ideal if the images are not the only focusable element - because then you should give focusable elements on your site the same tabindex to make sure that the tab order is not changed.

My opinion about this is still to just keep the wrapper <a> where it is. It is accessible and works. I already explained everything in detail earlier.

[wisniewski94]

TLDR; This element should be a button, which by its function is.

@arnowelzel

It is accessible and works. I already explained everything in detail
Also keep in mind the semantic here: the anchor tells the browser "here is something the user can open".

It's not accessible. Please check the attached video.

1. The link is announced with a terrible name, implying an element leads to an unknown page.
2. The clicked link will open dialogue which is even more confusing. As visually impaired user (which I am not) I expected to hear a new page title.
3. Sometimes screen reader will announce the element was visited (how can you visit a popup?).

Screen.Recording.2024-11-07.at.16.24.55.mov

This is quite a serious issue in terms of upcoming EU directive and similar regulations across the globe.

On the other hand, it will impact crawlers affecting SEO. I suspect these links could be caught by Google's tools such as Search Console and be marked as errors. I believe there could be more reasons to use HTML elements according to their original purpose that I can't think of right now. To summarize it - there are strong grounds to call this design an anti-pattern which has nothing to do with good UX practices or accessibility.

[arnowelzel]

You can always create your own frontend code to build whatever kind of lightbox collection you want. If you believe, that using "button" elements works better to open thumbnails - freel free to build it this way. At the moment I don't even know, how to build a "button" element which displays a thumbnail image and can be clicked as well and still links to the image in case JavaScript is disabled.

[arnowelzel]

On the other hand, it will impact crawlers affecting SEO. I suspect these links could be caught by Google's tools such as Search Console and be marked as errors. I believe there could be more reasons to use HTML elements according to their original purpose that I can't think of right now. To summarize it - there are strong grounds to call this design an anti-pattern which has nothing to do with good UX practices or accessibility.

Please show your solution to this. How would you create a picture gallery where one can click images which and where you can open the images by clicking the thumbnails without JavaScript as fallback.

Also I don't see crawler errors in websites using PhotoSwipe (the biggest site I am hosting has around 6000 images in galleries where the thumbnails are linked to the bigger versions using "a" elements and so far at least Google did not complain about that).

[wisniewski94]

@arnowelzel There's no point in raising an issue or having a discussion if the answer is "do your own better code". Of course, this is always an option, but it's not an answer to the messages I quote. I simply do not agree with statements similar or such as "this is accessible" and "this is perfectly fine". The message was - this is not accessible. That being said it's fair to say that the library is not accessible, which for most people, will be perfectly fine and you don't have to do anything with that knowledge.

But I am not sure if this is "good UX" since it creates a new problem: If JavaScript is disabled - maybe because the user does not want this for security reasons or there are security policies which forbid JavaScript by default - image links don't work at all.

Also, it's good to point out that there is a set of native elements that were meant to work in all possible circumstances. The lightbox element was never a standard element, and like any other custom and interactive widget it's supposed to be handled with JS to work correctly. ARIA attributes that should be in use here, also require a JavaScript to work. If you want a JS-free website that works, do not use custom elements.

The widget was built on top of the wrong criteria and because of this there isn't a better solution.