Skip to content

Conversation

detlevhfischer
Copy link
Contributor

@detlevhfischer detlevhfischer commented Nov 21, 2024

Closes #4095
A proposed addition to the 2.4.6 Understanding text that states that conventional icons can in some cases serve as descriptive label of form controls. Included is an example of a conventional icon (loupe for search).

See rendered version of the revised 2.4.6 Understanding text (updated 26 Nov 2024)

Copy link

netlify bot commented Nov 21, 2024

Deploy Preview for wcag2 ready!

Name Link
🔨 Latest commit 73c9310
🔍 Latest deploy log https://app.netlify.com/sites/wcag2/deploys/681366bcf502bb0008466af8
😎 Deploy Preview https://deploy-preview-4147--wcag2.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Wording changes to explanation of descriptive icon (different contexts affext interpretation).
minor wording changes
Changing "loupe" to "magnifying glass"
@detlevhfischer
Copy link
Contributor Author

detlevhfischer commented Nov 21, 2024

Sounds all very reasonable. Do you want to create a PR on my PR or do you want me to implement those changes?

@scottaohara
Copy link
Member

@detlevhfischer i provided them as suggestions so that if you agree with them, you can just commit them into your existing PR via GitHub's "commit suggestion" button that follows each of my proposed changes.

I would rather you be the one to commit these, as personally am against the idea of someone editing/committing to someone else's PR without explicit permission :)

@detlevhfischer
Copy link
Contributor Author

@scottaohara

as personally am against the idea of someone editing/committing to someone else's PR without explicit permission :)

I gave you permission, I suggested it :) - but no problem, I think your suggestions are good and I will work them in myself.

@patrickhlauke
Copy link
Member

patrickhlauke commented Nov 22, 2024

@detlevhfischer

I will work them in myself

just to reiterate, if it's not obvious: all you need to do is press the "Commit suggestion" for each here in github, no need to manually try to rework your PR

screenshot of one of scott's suggestions, with a red arrow pointing to the 'Commit suggestion' button below it in the github interface

detlevhfischer and others added 4 commits November 26, 2024 13:50
magnify glass -> magnifying glass
(assuming this is the more common term?)
@A11yTea
Copy link

A11yTea commented Jan 6, 2025

Hey I was just reading about this and I was thinking you might want to add a reference to 1.1.1 Non-text Content to make sure they have an equivalent alternative?

@bruce-usab
Copy link
Contributor

Discussed on backlog call 2/7 and made some minor changes. Moved to Ready for approval.

and last name. The first field is labeled <q>First name</q>, the second is labeled <q>Last name</q>.</dd>
<dt>A search field labeled by a magnifying glass icon</dt>
<dd>A search text input is followed by a button containing a magnifying glass icon that activates the search function.
The icon has the string "search" as programmatically determinable label.</dd>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A visible text alternative is also needed. Can we please add an according sentence?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this the whole point of this PR? clarifying that if an icon is "descriptive" enough, it doesn't need text?

Copy link
Contributor

@mbgower mbgower Apr 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is explicity stated: "In some cases, images can serve as descriptive labels without additional text."

Such an image needs a text alternative, but the author does not need to make the alternative visible, just programmatically available (which can be exposed to users in a number of ways, including visibly, through user agents and AT)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patrickhlauke does this work?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This addition would make it seem like all instances of images directly need to have alt text, when in reality the image could have no alt text because the form field’s accname is clear enough. Eg having a search icon with alt=search next to a text field with an accname of search is not what anyone should think they need to do in this situation.

To put it bluntly, this just seems to make this more complicated, and to provide the appropriate nuance, it’d submit more verbiage is necessary.

Copy link
Member

@patrickhlauke patrickhlauke Apr 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's the text input that needs an accessible name, not the icon/image used as visual label, basically. (which would cross-reference 4.1.2 and, depending how you look at it, 1.1.1)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, sorry I missed that. In that case, its basically only 4.1.2 that is needed not 1.1.1.

<p>Labels and headings do not need to be lengthy. A word, or even a single character,
may suffice if it provides an appropriate cue to finding and navigating content.
</p>
<p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.
<p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without visible text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.

@patrickhlauke
Copy link
Member

Mentioned this in the call, but for posterity/on the record: I do appreciate that first extra sentence

In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.

as this to me still leaves the door open for auditors to fail egregiously bad uses of icons without text. If an auditor makes a subjective judgement call that they believe the icon is not sufficiently understood/clear to users, they can still fail these icon-only labels (though, as this is subjective, there may be differing opinions ... but nothing that we don't already have in other cases).

Yes, conceptually, icon-only labels can be problematic for certain users - those who are unfamiliar with a particular icon, or users with cognitive disabilities. But I don't believe the original intent of the SC ever forbade the use of icon-only labels, and insisting that icons should always be accompanied by visibile text (next to the icon, or as a hover/tooltip, or by having a setting where a user can choose between "icon only" / "icon with text label" like some software does) would introduce a novel normative requirement by stealth here, I'd say.

@TestPartners
Copy link

It's ironic that the sentence "In these cases, authors should ensure that the image and its use as a label (in context) are widely understood" is followed by a button whose purpose I do not know because it has an unfamiliar (to me) icon and no text label or tooltip.

@A11yTea
Copy link

A11yTea commented May 1, 2025

as this to me still leaves the door open for auditors to fail egregiously bad uses of icons without text. If an auditor makes a subjective judgement call that they believe the icon is not sufficiently understood/clear to users, they can still fail these icon-only labels (though, as this is subjective, there may be differing opinions ... but nothing that we don't already have in other cases).

Yes if you leave that phrase in, we will start to fail icons that we don't find intuitive. I can confirm that as an auditor. I recommend removing the sentence or say that its a best practice.

@dbjorge
Copy link
Contributor

dbjorge commented May 2, 2025

Yes if you leave that phrase in, we will start to fail icons that we don't find intuitive. I can confirm that as an auditor. I recommend removing the sentence or say that its a best practice.

We discussed this comment in today's working group TF call and were in unanimous agreement that this situation is intentional and by design; we want it to be the case that auditors may choose to fail icons that are not "widely understood", per the wording this PR is using.

@mbgower mbgower merged commit 67450a7 into main May 6, 2025
5 checks passed
@mbgower mbgower deleted the detlevhfischer-patch-1 branch May 6, 2025 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2.4.6 Headings and Labels appears to prohibit the use of icons as labels

10 participants