Invalid <label> tags in quick links menu

[vkbo]

Inside the anchor tag in the list elements that make up the quick links menu, there is a label tag after the span that loads the fontawesome icon. I'm not sure why those label tags were added, but this is an incorrect use of label tags. They are intended for use with form input elements, not in anchor tags.

I'm happy to submit a fix, but I was wondering what the reason for them were first. They were added in #293.

pydata-sphinx-theme/src/pydata_sphinx_theme/theme/pydata_sphinx_theme/components/icon-links.html

Lines 13 to 24 in a55cb93

	<a {{ attributeString }}>
	{%- if type == "fontawesome" -%}
	<span><i class="{{ icon }}"></i></span>
	<label class="sr-only">{{ name }}</label>
	{%- elif type == "local" -%}
	<img src="{{ pathto(icon, 1) }}" class="icon-link-image" alt="{{ name }}"/>
	{%- elif type == "url" -%}
	<img src="{{ icon }}" class="icon-link-image" alt="{{ name }}"/>
	{%- else %}
	<span>Incorrectly configured icon link. Type must be `fontawesome`, `url` or `local`.</span>
	{%- endif -%}
	</a>

[drammock]

<label class="sr-only">{{ name }}</label>

The class sr-only means "screen reader only" I think. I'm pretty sure the label value is there to provide something intelligible for screen readers to say about those icon links.

I also think that this is not a proscribed use of the label tag; the relevant MDN page says

The HTML element represents a caption for an item in a user interface.

...so it's not just limited to form elements IIUC. Feel free to re-open if you think I'm mistaken or misinterpreting.

[vkbo]

I do think you are misinterpreting. The examples you show are all for input elements, and the html standard referenced also only uses it in the context of forms. In addition, the w3school page lists the elements for which it is valid, and last, but not least, the w3 validator explicitly states it's an error to use it in this way:

I cannot re-open the issue, only comment on it.

[vkbo]

As for accessibility aspect, I think the correct solution is to add an aria-label attribute to the anchor tag instead. I ran my website through an accessibility tool, and those label tags were listed as orphaned labels, so the tool didn't seem to know what they were for, which defeats the entire purpose.

[drammock]

thanks for the thorough explanation. Indeed it seems I was misunderstanding the MDN page (because I didn't read it carefully enough, which I now have). Sorry about that. Please go ahead with the PR fix!

[trallard]

Chiming in here to add more context from an accessibility POV in case @vkbo finds it useful for the PR

Indeed <label> is misplaced in this situation
and a more appropriate approach would be to adopt something like this:

<a {{ attributeString }}>
	{%- if type == "fontawesome" -%}
		<span><i class="{{ icon }}" aria-hidden="true"></i></span>
		<span class="sr-only">{{ name }}</span>
        ...
</a>

Where:

• the aria-hidden attribute is used to indicate whether an element is exposed to screen readers or not (it removes the markup from the accessibility tree, we have ariadescribedby somewhere else, so it is safe to use within focusable links)
• the sr-only class hides the element (visually) but keeps it accessible to assistive tech (I think that was the initial intent of the misused label)

Some references:

• Hiding elements from screen readers using aria-hidden
• Hiding things responsibly
• Aria hidden

[vkbo]

Thanks!

I'll make the PR this weekend. I'm a bit overloaded at work at the moment. But as I understand it then, there's no need for the aria-label to describe the a, as it would instead be handled by the sr-only <span> that it wraps?

[trallard]

Correct that way the link remains focusable and visible for screen readers (and not the icon itself).