Currently, the Lychee frontend misuses the <a> tag in both directions: it does not use them where <a>-tags should be used and it uses <a>-tags where they should not be used. Moreover the frontend does not set the href attribute correctly. This
causes problems for web crawlers such as search engines, and
has negative impact on the tabbing behaviour (i.e. which elements the browser jumps to when a user presses the tab key).
<a> tags constitute so-called interactive content (see MDN Docs: Content categories - Interactive Content). Interactive content elements should only be used for something the user can click onto (or interact otherwise with it), not for anything else. Moreover, search engines, e.g. Google, only consider <a> tags and there href attribute when they try to find links to other pages (see Google Dev Docs: Understand the JavaScript SEO basics).
Current situation
Currently, Lychee builds a photo element inside an album listing like that (an album element suffers from comparable issues):
This code uses <a> in four places where it should not be used at all: for the overlay subtext and for the three badges. None of them should is "interactive" or should be clickable by users. The only reason why we use it here is that we also use <a> for the small icons in the toolbar and we want to apply the same style for the icons in the badge.
On the contrary the whole photo is only a <div>, although this indeed represents a link to the photo page.
Intended situation
The frontend should adhere to the following principles:
Never use <a> tags for non-interactive content only to inherit a certain style; instead create a proper CSS class, e.g. like icon, if necessary and then apply this style either to an <a> tag, if it is indeed interactive, and use a <span> otherwise
For action button (like in the toolbar) which don't lead to another page but trigger an action, use <a> tags without a href attribute; these won't be considered by search engines, but are still "tabbalble" and considered by assistive technology as interactive
For links which lead to another page, use <a> tags and set the href attribute correctly
Note, a bound click event handler takes precedence over the browser's default behavior of following the href, hence unintended page reloads are not a concern
In order to make the href attribute actually useful, https://github.com/LycheeOrg/Lychee-front/issues/343 must be fixed, too. A search engine does not consider a URL with the same path but a different fragment to point to a different page, but pointing to another anchor (i.e. scroll position) on the same page.
Currently, the Lychee frontend misuses the
<a>tag in both directions: it does not use them where<a>-tags should be used and it uses<a>-tags where they should not be used. Moreover the frontend does not set thehrefattribute correctly. This<a>tags constitute so-called interactive content (see MDN Docs: Content categories - Interactive Content). Interactive content elements should only be used for something the user can click onto (or interact otherwise with it), not for anything else. Moreover, search engines, e.g. Google, only consider<a>tags and therehrefattribute when they try to find links to other pages (see Google Dev Docs: Understand the JavaScript SEO basics).Current situation
Currently, Lychee builds a photo element inside an album listing like that (an album element suffers from comparable issues):
This code uses
<a>in four places where it should not be used at all: for the overlay subtext and for the three badges. None of them should is "interactive" or should be clickable by users. The only reason why we use it here is that we also use<a>for the small icons in the toolbar and we want to apply the same style for the icons in the badge.On the contrary the whole photo is only a
<div>, although this indeed represents a link to the photo page.Intended situation
The frontend should adhere to the following principles:
<a>tags for non-interactive content only to inherit a certain style; instead create a proper CSS class, e.g. likeicon, if necessary and then apply this style either to an<a>tag, if it is indeed interactive, and use a<span>otherwise<a>tags without ahrefattribute; these won't be considered by search engines, but are still "tabbalble" and considered by assistive technology as interactive<a>tags and set thehrefattribute correctlyclickevent handler takes precedence over the browser's default behavior of following thehref, hence unintended page reloads are not a concernhrefattribute actually useful, https://github.com/LycheeOrg/Lychee-front/issues/343 must be fixed, too. A search engine does not consider a URL with the same path but a different fragment to point to a different page, but pointing to another anchor (i.e. scroll position) on the same page.