E-mail List Archives
Thread: Honeypots & SC 1.3.1
Number of posts in this thread: 4 (In chronological order)
From: wolfgang.berndorfer
Date: Mon, Apr 17 2023 3:29AM
Subject: Honeypots & SC 1.3.1
No previous message | Next message →
What looks like a heading must also have the technical representation of a
heading for SR. This is an example of SC 1.3.1 conformance.
But does SC 1.3.1 also include:
What is intended to be hidden visually must also be technically hidden?
I'm not talking about sr-only Information off-screen, but:
A honeypot to identify spambots is positioned off-screen, not with display:
none via CSS.
Thus, the input field is present for Sr.
Is this a failure of 1.3.1?
Thanks, Wolfgang
From: Patrick H. Lauke
Date: Mon, Apr 17 2023 3:59AM
Subject: Re: Honeypots & SC 1.3.1
← Previous message | Next message →
I'd say yes, it's a (mild) 1.3.1 failure.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ / https://github.com/patrickhlauke /
https://codepen.io/patrickhlauke
https://flickr.com/photos/redux/ / https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke
------ Original Message ------
From = EMAIL ADDRESS REMOVED =
To "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Date 17/04/2023 10:29:23
Subject [WebAIM] Honeypots & SC 1.3.1
>What looks like a heading must also have the technical representation of a
>heading for SR. This is an example of SC 1.3.1 conformance.
>
>
>
>But does SC 1.3.1 also include:
>
>What is intended to be hidden visually must also be technically hidden?
>
>I'm not talking about sr-only Information off-screen, but:
>
>
>
>A honeypot to identify spambots is positioned off-screen, not with display:
>none via CSS.
>
>Thus, the input field is present for Sr.
>
>
>
>Is this a failure of 1.3.1?
>
>
>
>Thanks, Wolfgang
>
>
>
>>>>
From: glen walker
Date: Mon, Apr 17 2023 10:56AM
Subject: Re: Honeypots & SC 1.3.1
← Previous message | Next message →
I'm not sure I see the programmatic relationship with the fake hidden field
to make it a 1.3.1. It might be a focus order or focus visible issue, but I
generally reserve those for input fields that are intended to be focused.
In this case, the input field is for preventing spambots so it has a
purpose but isn't really intended for users to navigate to it. You could
potentially have sr-only text to explain what the field is for and even
visible explanatory text that displays if you navigate to the field with
the keyboard (kind of like how some skip links appear when you tab). But I
suppose there's a potential that that might prevent the spambot from
accessing it.
In general, though, I agree with Patricks that *if* it's a failure of some
sort, then it's very mild, if that. And that might be explained away by an
"exception" rule that many guidelines have such as 3.3.3 that says "unless
it would jeopardize the security or purpose of the content".
From: wolfgang.berndorfer
Date: Wed, Apr 19 2023 9:37AM
Subject: Re: Honeypots & SC 1.3.1
← Previous message | No next message
Thank you, Patrick, for your estimation!
There were no more concerns, so Iâd sum up:
1. If a component (e.g., a honeypot) is intended to be generally hidden, is visually hidden, then it also must be hidden for SR.
2. If not hidden for SR accordingly, Sc 1.3.1 is violated at least mildly.
Wolfgang