Web Accessibiity

Hi @corkcork

Can you provide which field(s) the reports are coming in for?

I have a hunch it may be for a field that’s meant to be visually hidden to users and not filled in at all by humans, as part of our spam prevention, but it may be other items as well.

Also if able to share, the tools/links you’re using to do your accessibility testing with would be awesome so we can do more thorough review/checks on our own as well, with the same tools.

I think you are right, is it visibly hidden from view, but still detected with the accessibility checker. Here’s the entire tag that it’s detecting:

` <input tabindex=”-1″ class=”ctct_usage_field” name=”ctct_usage_field” value=”” type=”text”>

I’m using https://www.webaccessibility.com

Doing some digging in and research on if there’s any ways to indicate that that field should be ignored, so we can put the appropriate markup into the plugin for that file.

Don’t have an answer for you just yet, other disregarding for the moment.

Edit: forgot to say that that definitely is our honeypot field.

• This reply was modified 3 years, 10 months ago by Constant Contact.

Okay, thank you. Keep me posted on an update.

Just filed an internal enhancement issue around this topic which is suggesting we follow the advice from the “Honeypot” section of https://www.accessibilityoz.com/2014/08/captcha-right-ie-dont-use-captcha/

We have the label already, but we missed the ID attribute on the field itself, which will be amended. The other part is we will likely add in some wording for screen readers saying to not fill that specific field out.

Hopefully that handles all the accessibility flags that the form raised when your page was run through that tool.

When will the new release be ready?

Admittedly can’t make any promises on timeframe for releases, but I did nudge our developers about what we could do to move things along a bit more and include changes around this topic here.

Did your manual changes resolve the logging as an accessibility item in the meantime? or did you remove those since we chimed in about it all?

If push comes to shove, I can provide some spots to go to and what to change to attempt helping get those temporarily removed.

I didn’t make any changes because I don’t know which files need changed. Could you please tell me which file and line number to change? And which code needs to be added?

Biggest thing is going to be in this spot:

public function build_honeypot_field() {
	return sprintf(
		'<div class="ctct_usage"><label for="ctct_usage_field">%s</label><input type="text" value="" name="ctct_usage_field" class="ctct_usage_field" tabindex="-1" /></div>',
		esc_html__( 'Constant Contact Use.', 'constant-contact-forms' )
	);
}

It should be line 541-546 inside the includes/class-display.php file.

You’ll want to make those lines read something like this:

public function build_honeypot_field() {
	return sprintf(
		'<div class="ctct_usage"><label for="ctct_usage_field">%s</label><input type="text" value="" id="ctct_usage_field" name="ctct_usage_field" class="ctct_usage_field" tabindex="-1" /></div>',
		esc_html__( 'Constant Contact Use. Please leave this field blank.', 'constant-contact-forms' )
	);
}

This should satisfy the label/field ID pairing as well as add some context for screenreaders.

Hi, thank you. That worked great! Now, the web accessibility checker is flagging the submit input fields for the Constant Contact newsletter submit buttons. Below is what it is saying. I’m not sure why it is thinking that the input field is not well-formed. Maybe you can help me out with this?

Ensure markup documents contain well-formed elements
Severity: 6

Documents that use markup languages must be well-formed. When documents are not well-formed user agents and/or assistive technology may not correctly parse and render the content to users. Many major user-agents are able to cope well with "bad" markup, however, to be consistent across all platforms and browsers well-formed markup must be used. This is especially important for assistive technology which may or may not be programmed to perform the same level of "coping" that can be found in browsers (which are created by multinational corporations) or assistive technology brands that cost several hundred dollars or more.
Violations Identified (2)

<input id="ctct-submitted_0" class="ctct-submit ctct-label- ctct-submitted" placeholder="" value="SUBSCRIBE" name="ctct-submitted" type="submit">

Glad to hear that first part got cleared up.

Regarding the new on, I’m curious if that ctct-label- is throwing things off slightly, as well as the placeholder usage on a submit button. Will open issues for this as well though, this is going to be a little bit more difficult to spot fix.