There is a text input form associated with mollom with id="edit-mollom-homepage" which doesn't have a label or title associated with it. It was difficult to find using WAVE because the input field is hidden.

I don't understand why this input element is hidden (via CSS) input element but it would be good to find some way to communicate what this field is and why it should be left alone by folks using screen readers.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

I think this was on purpose. The code comments says "Add a spambot trap. Purposively use 'homepage' as field name." So you weren't supposed to notice it.

mgifford’s picture

It would be better if it were:

<input type="text" id="edit-mollom-homepage" name="mollom[homepage]" value="" size="60" maxlength="128" class="form-text" title="homepage">

Which would get around the accessibility problem the validator is seeing. It would also make it more convincing for the spanners I figure.

Anyways, it should be a pretty easy fix although screen readers won't see it since it uses CSS's display:none;

However, if user has disabled CSS then that would be an issue....

Mostly it's for validators however.

sun’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
Status: Active » Needs review
FileSize
456 bytes

So you're saying that this patch makes WAVE stop complaining?

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

Yup. And for other automated testing tools it's useful too. It's hard for the bots of any sort to see the if an element is visible or not...

I applied it here and it's working fine:
http://openconcept.ca/blog/mgifford/accessibility-tips-management

Thanks!

sun’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

mgifford’s picture

Thanks sun!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

sun’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Closed (fixed) » Active
FileSize
1.46 KB

Unfortunately, I've to re-open this very old issue. :-/

Turns out that Mollom Support frequently receives false-bug reports from site owners, who happen to use JavaScripts that are trying to mimic HTML5 placeholders.

Unlike http://drupal.org/project/compact_forms and other sophisticated JS libraries,

  1. There are a bunch of bogus/poor implementations, which are copying the 'title' attribute into the 'value' of form input elements.
  2. They then attach a form submit JS event handler, which is supposed to remove the injected values, but sometimes that can fail, due to JS errors on the page halting all script execution or other unfortunate circumstances.
  3. Some site-specific/custom implementations do not even attempt to clean up their mess to begin with... submitted form values always contain the placeholder values, unless a user/visitor filled in custom values...

In turn, such sites are running into massive false-positive spam classifications, and they obviously point the finger at Mollom... even though the bug is clearly caused on the client-side. :-/

While the root cause is very clear and, technically, the wrong party is blamed, I only recently noticed that this happens way too often and I do not want that to continue, as it harms Mollom's reputation, and also causes a lot of work on the Mollom Support end.

So, attached patch is my starting point. Removing the 'title' attribute that we previously added here.

The essential question is: Is there any way to mute/hide an input element completely from screen-readers?

Or... actually, not screen-readers. The only piece that ever complained here is the WAVE validator. So is there any other way to make WAVE stop complaining?

Due to the reasons outlined above, I'm highly tempted to commit this current patch in either case as-is. Especially as the root cause for adding the 'title' attribute was not actually that screen-readers would wrongly run into the trap, but instead, just a WAVE validator warning message. Of course, it's tough to balance the importance of a "bogus HTML validator message" vs. "completely bogus JavaScript". But since the latter has actual, hard implications on innocent end-users on many sites, it definitely has a higher priority here.

mgifford’s picture

You can just use css display:none; to exclude something for screen readers.

There are also might be a way to just replace it with ARIA.

sun’s picture

Status: Active » Needs review

Thanks, @mgifford! The field is already wrapped in a DIV container with a style attribute of display:none. However, that's still the same as we had originally, and you originally created this issue, because WAVE complained about the input field (despite being hidden). :)

Perhaps the WAVE validator has been fixed in the meantime? :)

sun’s picture

Status: Needs review » Fixed

Committed to 7.x-2.x and 6.x-2.x. Thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 357793c on master, fai6, 8.x-2.x, fbajs, actions by sun:
    Issue #1147160 by mgifford, sun: Fixed accessibility validation of...
  • Commit 6759bd8 on 7.x-2.x, 8.x-2.x, fbajs, actions by sun:
    - #1147160 by sun: Fixed 'title' attribute of honeypot field is injected...

  • Commit 357793c on master, fai6, 8.x-2.x, fbajs, actions by sun:
    Issue #1147160 by mgifford, sun: Fixed accessibility validation of...
  • Commit 6759bd8 on 7.x-2.x, 8.x-2.x, fbajs, actions by sun:
    - #1147160 by sun: Fixed 'title' attribute of honeypot field is injected...