I have a honey pot input field on a form to prevent bots from submitting it, hidden with absolute positioning. I would like assistive technologies such as screen readers to ignore the honey pot field, so I added the aria-hidden="true" to it.
Will adding the aria-hidden="true" attribute to my honey pot field prevent bots from filling it in, similar to adding a "display:none" property? Or will they still fall for the trap and fill in the field?
Form fields are tab focusable, so while adding aria-hidden will not cause the field to be announced, it will still receive focus when a screen reader user tabs through the page.
This will cause confusion because the screen reader will not read out any label for the field. To solve this problem, you could add tabindex="-1" to take the field out of the natural tab order. I am not sure, however, whether that will cause it to be ignored by the bots.
Will adding the aria-hidden="true" attribute to my honey pot field prevent bots from filling it in?
No. They read Stackoverflow like everyone. After reading your message, they will update their algorithm and ignore aria-hidden=true fields ;-)
Of course not. As long as this solution can be skirted, writing it publicly does not give you the benefit of security through obscurity.
EDIT: added a smiley (but this is however a serious answer)
EDIT 2: added a second sentence for people lacking of humor
Related
We have a project at my work at the moment around ensuring we meet accessibility standards on our website.
Our emails are built using Salesforce Marketing Cloud layouts. Does anyone know how we can see or test how 'accessible' they are?
I can test using ReturnPath to see how they render on various devices and that gives me results for colour blindness, but I'm not sure how to test how well they would or wouldn't work with a screen reader for example
Emails are a tough one from an accessibility perspective. We are still stuck using tables for layout even in 2021!
We can't use WAI-ARIA and CSS is very limited.
As such I have a smaller checklist for emails that covers the important stuff we can control.
The main things I would look at are:
Reading order
Make sure that the email reads left to right and then downwards (assuming the language is a left to right language, otherwise reverse it)
Use headings
Email marketers often just style normal text instead of putting proper headings in. Make sure headings are in fact <h2> to <h6> with a single <h1> explaining the purpose of the email at the start.
Also make sure that the headings do not skip levels (so don't go from <h2> to <h4> for example).
Colour contrast
The exact same rules for websites apply to emails. I would recommend running the colours through the Web Aim colour contrast checker for your text and background around the text, button backgrounds and text etc.
Alt Attributes
Alt attributes on images is the big one you need to check for especially in emails where images might be the only content within a hyperlink. As you can't use aria-label or visually hidden text in an email alt attributes are the only way you can make a link have meaning if it contains an image (plus as email clients block images it means there is meaningful text for everyone else not just screen reader users).
Meaningful Link Text
Along the same lines make sure links do not just say "Read more". Instead make link text meaningful e.g. "Read our article on X Y Z".
Use a descriptive subject line
This one is the only one that is "difficult" as a marketer. You want subject lines to intrigue people to open the email, however for people with cognitive impairments cryptic subject lines can be disturbing / confusing etc.
Getting the balance between "giving the game away" and meaningful subject lines is difficult, if unsure err towards meaningful (it may help your open rate / conversion rate anyway so A / B test it!)
View in Browser
Due to the limitations of email clients the best way to ensure accessibility is to have a custom "view in browser" link in the email (as salesforce etc. are very unlikely to do a good job of the browser versions of their emails).
That way you can use WAI-ARIA, visually hidden text etc. and mark the page up properly, complying with WCAG 2.1 (and very soon WCAG 2.2) requirements.
Obviously I am aware of the amount of work this entails but once you have a template and components built that are accessible it does become much easier.
Testing
Personally I would just test manually, but I am sure somewhere out there an email testing service exists similar to Axe Accessibility Checker.
But given the length of a typical email I would say a manual check will only take 2 minutes once you know what to look for so a service may not be worth it.
You could always copy and paste the email HTML into a file and save it with a .html extension and then open and test it in a browser / accessibility checker. But you might get a load of issues you can't resolve due to the use of tables for layout.
Finally - learning to use a screen reader takes less than an hour, grab NVDA or VoiceOver and test the email yourself, if you can understand it and access all the same information as everyone else then send it!
Does anyone know how I should handle aria-labels on link labels that repeat dozens of time on a page? My website accessibility checker tool keeps flagging these elements as using the same link text for these labels and they require unique aria-labels. Problem is, all of the links go to the same generic pages and am not sure how to make the aria-labels specific enough.
Has anyone dealt with anything like this before and how did you handle it? I imagine I'd need a JS solution to inject aria-labels, but before I invest in a JS resource doing this for me does anyone know how I can make these specific enough to pass the checker but not confuse screen readers?
Screenshot of category labels for each article
In this case, it is correct to hide all duplicate links except for the first element that contains these labels
You force people with disabilities to navigate through all the same links using keyboard navigation, this is also bad for a screen reader
1.) Hide any duplicate labels from your screen reader
aria-hidden="true"
2.) Hide any duplicate labels from keyboard navigation
tabindex="-1"
Note! don't forget to leave one unique link! You can also hide everything and add them to context under elements or above elements. When I say hide, I mean the above methods.
It's easy to check for accessibility, close your eyes and imagine you click on a tab and hear (in a screen reader) a re-link through every two elements! This is annoying isn't it?
There is no need for aria-labels and what you are doing is not an accessibility fail. You have to bear in mind the automated accessibility checkers are dumb (and in this case quite possibly wrong) and are only there to offer guidance on common accessibility fails.
The main reason you are seeing this is that the accessibility checker thinks that this is text like "read more" that is not descriptive of the end-point. It should pick up the fact that the end-point is the same but it obviously does not.
Using the same link text for links that go to the same page is encouraged:
It is a best practice for links with the same destination to have
consistent descriptions (and this is a requirement per Success
Criterion 3.2.4 for pages in a set). It is also a best practice for
links with different purposes and destinations to have different
descriptions.
Source: https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html
Also one of the checks for success criterion 3.2.4 - Consistent Identification is:
Check that this associated text is identical for each user interface
component with the same function.
Source: https://www.w3.org/WAI/WCAG21/Techniques/general/G197.html
Assuming your articles are marked-up correctly a screen reader user could skip between headings (<h2>s for example) in order to not hear the same category links. This is one of the primary ways a screen reader user will navigate a page (via headings).
For this reason the categories should be AFTER the heading in the HTML so that they are read out after the heading.
You could place the heading visually after the tags using techniques similar to those in this answer I gave. This would be acceptable for "logical tab order" in my opinion so you wouldn't fail there.
Your only other option would be to use aria-hidden="true" and tabindex="-1" on your category links to hide them from screen reader users and take them out of the tab order. If you did this you would need to ensure a categories list is available at the side of the page.
Personally I would go with the first option as the categories information is useful to screen reader users, the fact the links repeat themselves over and over if I search by links would indicate they are categories to me when using a screen reader anyway.
If I display:none over a form wrapper on my website contact page will a spam bot still be able to submit it?
If no, then would a possible solution be to just place a link saying - send us an email - and when clicked it display:show the wrapper with the form thus this preventing spam?
Thanks,
-O
A spam bot is usually a script that is executed and run automatically. It's not an actual human being so the bot would not care if it is actually hidden by the style or not. You could add it to the DOM in the moment the user clicks a button if you wanted to prevent a "spam bot" to abuse it.
There are many different types of spam bot out there, and many different approaches used in filling in your form (and thus: sending you spam).
For the most part these are automated scripts which don't actually 'see' the page at all but simply use the markup it finds on-page. To that end, using CSS to hide a form won't stop them at all.
On the same vein: you'll find that there are a lot of bots out there which will scrape your email address and send you spam directly if you leave a mailto: link on your site.
There's no sure-fire way of stopping spambots I"m afraid. There are a lot of techniques that you could employ to reduce it though.
The most common is to use a captcha service like recaptcha although even this isn't a concrete guarantee that some spam still won't filter through.
The other trick I tend to employ is a Honey Pot input which is relatively easy to employ and seems to do a fairly good trick of keeping the spammers out.
Spambots are meant to be fast, and they don't parse CSS or JavaScript. If you want to protect against them you can include a CAPTCHA, even a simple one, like asking the user to write the sum or product of small numbers (obviously write the request in a sentence, using letters and not numbers). A cheap solution like this should prevent most spam, but it's easily attackable, if someone wants to target you.
I wouldn't suggest to create dynamically the form, since users that aren't capable to execute JavaScript wouldn't be able to see it.
If using a honey pot, which is the most user friendly, simple and extremely effective, try not to hide your input field with the css hidden command. Bots can see this if they are complex..
Position the field absolutely at the top of the form, to the left or right, have it with no border, and the background and text colour the same as the element the form is within.
We're building a site for an academic institution. This institution offers many subjects, and we don't want to show all of them at once on the homepage. So we designed a homepage that shows the 2 main categories of studies, and clicking on a category will show a div with the list of subjects in that category.
Our client is worried SEO-wise about those div's being hidden on page-load. Is he correct in his concern?
It depends on how you hide them if you use a z-order or a far left off screen position they will still be read by the Google bot. if you use display none or hidden then it may have an effect on your SEO.
You're right to have concern. Google will count some of or significantly reduce content that isn't displayed on page load. I would recommend letting the text display at load, then setting it to display none via JavaScript. This way the search engine picks it up.
You can do so with a simple jQuery hide snippet like this:
<p class="remove">Text displayed on load.</p>
$j(document).ready(function(){
$('.remove').hide();
});
I read an article by Roger Johansson on this subject, and it seems that the conclusion is that as long as the intent isn't to show that content only to search engines, hiding is fine. I don't see any mention of preferring one method of hiding over the other.
In addition, in that post's comments there was a link to an answer by a Google worker that said:
Merely using display:none will not automatically trigger a penalty. The key is whether or not there is a mechanism - either automatic or one that is invoked by the user - to make the content visible
In my case of course there will be such a mechanism, because we want our users to see that content, just not at page-load...
Is it good for user experience to duplicate browser/keyboard functionality?
For example: to provide these links on a web-page.
"Back to top" link
"Print this page" link
"Add to Favorite" link
"Back" button/link
"Text zoom" button alt text http://shup.com/Shup/344995/110421205515-My-Desktop.png
Are they really create Site's usability and accessibility?
How screen reader will behave these links, will these confuse to screen reader users?
Many people haven't gotten into the habit of using the Home and End keys to go to the top and bottom of the page, so I don't find Back to Top links highly objectionable.
Print this page links can present a printer-friendly page, instead of the main page which is generally littered with banners and other stuff.
Add to favorites - Not a big fan.
Back button - Can be useful in workflow scenarios, but it better do exactly the same thing that the back button in my browser does. Generally the more common pattern is to provide a link, with describing text, such as "Return to Main Page."
Text Zoom Button - Love it. It allows me to tweak one site, while retaining the settings in my browser for other sites.
As a screen reader user I don't really care one way or the other. Listening to a couple extra links doesn't make a difference to me. Screen reader users are generally going to be a very small minority of the visitors to a site. If adding links such as top of page or add to favorites makes the site more usable to non screen reader users I would say add the links since it is something that's very easy for screen reader users to ignore. If you are writing a site specifically targeted at screen reader users then you may not want to add the links since they would be the majority of your users.
Adding such links should be motivated by a scenario. If users normally would print the page at a certain stage of the workflow when visiting your page, then it will be much more convenient for most of the users if the specific command option is directly visible and can be executed with a single-click.
Scenario: A user wants to buy an online ticket. They will select the event, choose a category, enter their personal details and billing information the finally will print the ticket. Instead of leaving the user alone at this last step and make him search the browser menus simply offer the print option inline in the body of the page.
I would say it was generally a very bad idea; the screen reader would definitely include ways of accessing the browser's implementation of that functionality, and duplicating that just wastes their time.
I would say that boilerplate-text is almost always bad for screen reader users.