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.
Related
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.
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...
I would like to know at which stage is it okay to start manipulating HTML elements/content using Javascript so as not to impair SEO?
I have read somewhere that HTML content that is hidden using the CSS property display:none is often penalized by Google crawlers, with good reason from what I'm led to believe...I ask this as I intend to have some div panels that are initially hidden, but shown once the user clicks on an appropriate link. My intention is therefore not to hide content from users entirely - just intially to give them a better user experience - I'm afraid Google may not see it that way!
My reason for doing this is to prevent the split second (or in some cases, a full 2 seconds) of ghastly unstyled html elements (positioning), before my Javascript comes in to position, hide and neaten everything up. So adding the display:none at the forefront, and then using Javascript to toggle visibility would have been ideal, but is apparently a no-no with Google Search Engine bot.
Do you experts have any advice? Thank you!
google can now crawl AJAX sites using a simple URL substitution trick; you might be able to take advantage of this to let googlebot see a plain html version of the page for indexing instead of your load-optimized page; see http://code.google.com/web/ajaxcrawling/docs/getting-started.html
If the content in question exists on the page in the html, and is accessible to the user by the time the page finishes loading initially, then you are okay. You want to make sure google can lead a user to your page and see the content in question without requiring further interaction. Adding new content to the html after the initial load (i.e. content from the server), can be problematic for SEO. However if all content is in the html by the end of the page load, then you shouldn't get docked. Keep in mind, good SEO strategy dictates using standard methods of usability so the web crawler can access your content.
Also, each page should follow a content theme. Example: Don't abuse users by hiding five different unrelated blocks of content "medical devices, kazoos, best diners, motorcycles, toxic waste" on one page. Theoretically you could take all of your site's content and lay it out on one page using javascript and 'display:none' waiting for an 'onClick', but that smells like spam.
EDIT, additional info as pertaining to the original question:
The search engine friendly way to display content dynamically is to load it, then hide it from the user.
I notice that when I try to access Stackoverflow through the reddit toolbar, I get a popup that says "For security reasons, framing is not allowed". See here for an example.
What exactly are those security reasons?
I realize that this might be a question for meta, but it is really more of a general web security question, so I'm giving it a shot here.
Thanks.
You can check the story on that in here.
EDIT:
Ok, so quoting from the link the problem with framing is that it's the first step to clickjacking. How is that accomplished? You can have an apparently harmless page with links which have on top of it a frame with full transparency that was carefully positioned so that when you click the links of the page, you'll be clicking links or buttons of the framed page. Although you can't see the frame (due to full transparency), your clicks will be caught by it. This results in, while the user is lead to thinking that he's just navigating on a random page, he may be actually changing his twitter status, sending emails, doing something on facebook, clicking a paypall "Yes please donate it all" button, ... imagination is the limit.
To protect its users from click jacking attacks. In simple words click jacking works like this:
The attacker hosts the malicious html file
This file loads the 'attacked' website in the background using a frame and by overlaying elements on top of the 'attacked' website it tries to trick the users into clicking something they didn't want to.
If an evil website decides it's going to frame your website, you will be framed. Period
Wrong. Mechanisms like the one implemented here in stackoverflow protect websites from being loaded inside another possibly malicious page. This way the site protects its users against click jacking attacks.
f that is the case, why do it at all? Furthermore, the target of the attack is not necessarily the site being framed, it could be any site. So again, why bother busting the frame?
The frame is used to load the 'victim's website inside a page that will try to trick the users. Busting the frame means that the site is blocking these possible click jacking attacks. Or at least adding an extra layer of security since these 'filters' can also be bypassed.
Read the original research paper about click jacking
Apparently there is a tiny chance of a possible click-jack attack as demonstrated here:
http://dsandler.org/wp/archives/2009/02/12/dontclick
So I guess it kinda makes sense, but it is awfully inconvenient.
Understanding all the security and UI concerns with iFrames, I am implementing a toolbar similar to the DiggBar or FacebookBar.
A top bar persists across the top 30 pixels of the screen, and an iFrame displaying external content fills up the remainder of the page.
When users close the toolbar, and thereby exit my little site to go directly to the third-party site, how can I bust the iFrame properly and display the right page? If the user clicks on even one link in the iFrame, I end up showing the wrong page.
Given my understanding of browser security, and coupled with how DiggBar and FacebookBar fail to do this accurately, I'm guessing it cannot be done.
But I was hoping the Stackoverflow coders are smarter and might have an answer? :)
Thanks!
You can't. Because of browser cross site-scripting security, your bar which sits in its own frame cannot access any other frames and determine their URLs.
Not to mention that'll you'll be sued by website owners for numerous things and that you'll piss off every hacker out there.
This is the last thing you want to do if you'd like to NOT in your our office as that one guy who wanted to include everyone elses web site in their website with the owners permission.
I wouldn't speak up at any of the conventions either.
I've also added the question: "Have you ever written code or worked on code that frames other sites?" to my list of questions to use to weed out job applicants.