Related
I have been told by my boss to add tabindex="1" to the Accessibility link in our site footer so that it will be the first thing that someone who browses a site by keyboard can get to and read about the accessibility steps we take.
I have added tabindex="1" to the link which you can see here, but the browser doesn't seem to respect it at all (tested in Chrome/FF/IE 11). There are no other tabindex attributes on the page that I can see, so surely it should get picked up as the priority by the browser.
There are access keys used on the page, could this throw it out in some way?
I am sure it is something really fundamental, but I can't see what it is. Any help would be appreciated.
Thanks
It works for me, but as a long-time accessibility advocate I'd like to help persuade your boss it's a bad idea.
To see it working I suspect you are on a Mac and you need to enable keyboard navigation. People who need that would typically have it on already.
However, the reasons that adding a positive tabindex are not helpful include:
Someone using a keyboard (or keyboard equivalent device) and can see the screen will be confused. They press tab and suddenly end up at the bottom of the page, then flip back up to the top. Combined with the lack of focus visibility, this will be very difficult to cope with.
Someone using a screenreader will probably not notice the tabindex to start with because the main way of navigating is with 'arrowing' (using up/down to go element by element). However, if they are in the content area and press tab to skip to the next link or form control, they will suddenly go to the bottom of the page. Very confusing.
So in summary: Adding a positive tab index on a link in the footer will negatively impact the people it is supposed to help.
Here are the appropriate ways to use tabindex.
There are quite a lot of obvious accessibility issues on the site, I'd recommend getting some advice.
Windows and OS X have always bumped heads on this, but what is the general concensus on whether a Save button or Cancel button goes first in a web application?
[Save] [Cancel]
or
[Cancel] [Save]
Note: I have these buttons at the top of the form flush to the right.
Follow the principle of least astonishment: do it the Windows way ([Save] [Cancel]) unless you have reason to believe that Mac users make up a greater portion of your user base.
The key here is that we are talking "web" usability. To that point, I think it is pretty clear that the principal of least astonishment referenced in the accepted answer would suggest that right is the forward action (save) and left is the backwards action (cancel), and not what the accepted answer suggests.
The web browser is the user interface web users are most accustomed to, and 15+ years of web browsing has made it pretty clear that the back button is to the left of the forward button. It also jives with the left to right based languages that the web was initially developed for. The right is where you are going, the left is where you have been.
Even in general computer vernacular, a forward slash, /, leans right while a back slash, \, leans left.
The windows UI is the outlier here, and I think it is a poor decision to base your UI design on Microsoft's precedence.
I might point out that your top right corner positioning of the two buttons is non-standard, but I don't think it bears on the ordering of the buttons themselves.
Instinctively I always put the Save button as the rightmost element.
I think there are other things to consider. Primarily whether a Cancel button is actually needed, or whether another element (such as a breadcrumb trail pointing to the previous page) might be more appropriate.
Edit: http://www.lukew.com/resources/articles/web_forms.html - The section 'Primary and Secondary Actions' shows how visual weighting can be used to good effect as well.
For all the heated arguments this issue can generate, it doesn’t seem to make much difference in actual human performance. The advantages and disadvantages of each work out to a wash. Users appear equally likely to expect Cancel on either the left or right in web forms. There appears to be a bias to favor Cancel on the left if the buttons are widely separated, but you don’t want to do that since putting the Execute button the far right is associated with slow responses and high error rates on web forms.
I’d say the most important thing is to be internally consistent in you app, and be sure Cancel is always labeled “Cancel” (not, say, “Return” like I saw in one web app). Otherwise, put the buttons next to each other and near the last field the user will look at (which is probably not in the upper right of the form).
And don’t worry about it too much.
It's probably not a big difference either way, as long as it is clear what the buttons do.
My personal vote would be to have save on the left, as that is what people do the most often, and people read left-to-right.
Also, I would also put some space between the buttons, to make sure users don't accidently click one when they are trying to click the other.
Why do you need a cancel button at all?
On a web form, the user can almost always cancel through some other action. Putting "Cancel" near "Save" is creating a situation where the user has a good chance of firing the ejection seat when all they want to do is save.
I generally put the button which will cause the most actions to occur farthest away from the center. If your buttons are top-right, my order would be [Cancel][Save]
Familiarity is often more important than being objectively correct, since things that are unfamiliar are often, by default, less usable.
People use their Windows PC or their Mac more than your app or website. So if I were in your shoes, I'd pick the order which you think will be familiar to the users you care most about. If it's a mostly-mac audience, do it the mac way. If mostly PC audience, do it the PC way.
On a normal form, Save should be under the form fields. Cancel should be to the left or right of Save, but not too close to avoid tragic mistakes. Luke W's Web Application Form Design page has some illuminating diagrams.
Your form is unusual in that you want the buttons to be at the top. In this case I'd need to know what the page looks like and how it will be used. But since you're already breaking any flow between form fields and Save, I suspect Save should be on the right to support the natural left-to-right path.
(Windows and Mac have differing standards for button placement on dialog boxes, and they both have the buttons at the bottom. These standards do not apply to web pages.)
I have made life difficult for the HTML / CSS developers by making any interaction that has a side effect into a button and NOT a hyperlink.
For example I changed the "Clear Basket" in a shopping site from a link to a button.
On the premise that any action that has a side effect should be a button not a hyperlink. (even tho a spider or robot will never get to this point)
How does this relate to REST?
The best answer will have good reasons I can use as to why I make things difficult for the HTML/CSS guys,... or why I'm wrong :-) ,... perhaps I'm being purist but for no real reason?
Note: I'm not averse to putting ajax functionality that has statefull side-effects on a hyperlink or even on selection-changed event.
Cheers.
Murray.
I think you did the right thing but justifying it is probably outside the domain of "REST".
If these links are truly just <a> tags that result in the browser making a GET request then clicked, then they shouldn't have any side effects because GET is supposed to be, per the HTTP spec, safe and idempotent. See earlier comments about spiders following the links, etc.
Now if the "links" used javascript to really do a POST to the server when clicked, or some kind of trick like that, then they are A-OK from HTTP's point of view. Probably more work than they're worth, but RESTful.
But there is user interface design to consider too. Because in basic HTML without CSS and javascript a link is always a GET, users have been trained since 1994 to expect anything that looks like a hyperlink to be safe and idempotent. By doing something different, your designers are in violation the principle of least surprise. This seems like something Jacob Nielsen would back you up on.
This doesn't really have much to do with REST, but I try to follow this simple rule:
Hyperlinks are for navigation.
Buttons are for interaction.
It does not really matter if your "stateful" actions are links or buttons. You can have a link that deletes/adds, etc. Consistency is what matters. So if you want to have these actions be buttons, that is fine. I think that talented CSS people can make links look like buttons. You may not need html buttons at all.
When are appropriate situations to use the target="_blank" attribute on your hyperlinks?
Edit:
To clarify, I know the syntax will open a new browser window. What I am asking is when is it appropriate to do so?
Whenever you want to annoy users.
More seriously, since this opens a new window/tab, it should be used sparingly, in my opinion.
Most modern browsers have some option (ie: middle-click on hyperlink) to do this for you, so I personally prefer allowing the user to handle this themselves.
However, if you are working on something where there is a non-technical reason for this, such as a sales-oriented site, it's often desirable to open a product brochure in a new window, or something along those lines. However, just be aware that overdoing this leads to my pseudo-joke response above....
When ever you want to leave the current page as-is.
I've got a feeling your question should be 'When is it appropriate to open a new tab or browser window?'
If so, the answer might be :
The current form may be in edit mode, and you want to be able to open
another page without either
disregarding or saving the current
one.
You have a data stream like Twitter which you want to leave active while
you go off and look at X.
There is a specific business requirement to do so.
Your users have weak navigation abilities and won't find their way back to the main page.
It is most appropriate when you're linking to outside resources that people may want to go to for additional information, reference, etc.
It lets them leave your site without losing their place on your page or have to use the back button.
It also makes sure they have to look at it one more time if they want to close it ;-)
(that last one is a joke and I don't advocate such despicable practices of course...)
Generally I avoid it like the plague. However, perhaps a good example of why you'd want to use that would be if you're building a cart module or something, and you have the "click for bigger picture" link. I think it's ok in that sense.
Keep in mind that whenever you do it, you're assuming you know the user's workflow better than they do (they can always open the link in a new window without you forcing it). In the case of the "bigger picture" link, you'd most likely be correct in assuming that's what they want, but in most cases I wouldn't jump to conclusions.
When you want the link to open in a new window, I would assume. I think the time to use this is when people might click on a link that'd destroy what they were doing on the page currently, such as a "help" link on a form.
Though some would argue that you should never use target="_blank".
One thing to be aware of here is accessibility. Built in features to help blind users (text to speech for example) may act weird (or just in a way that's confusing to the user) when you open a new window or tab.
Also, you're breaking the most used feature of every browser...the back button.
Only if it, with outmost certainty, prevents the user from having to repeat something.
I think that you should probably not ask a user experience question in a developer forum, because you will get developer answers.
That said, and as a developer, I open new Windows when I expect (or want) the user to come back and continue working on the site where the link originated.
The only time I would consider it is if you have multimedia on the page.
Best example I can think of - the StackOverflow podcast... I can't tell you how many times I've rushed to click a link in the blog post only to take me off the podcast page!
Also, on YouTube when I click "View Comments", it takes me away from the video page.
Whatever you do, don't use JavaScript to open a new window. That's definitely the worst. Nothing worse than a middle-click only to open a new tab with javascript::garbage in the address bar.
The target="_blank" is deprecated in XHTML 1.0 strict, and since I only write in strict I use JS if I really want to open a new page (or tab) and I only do that for external links (like a wiki or so).
More info:
http://www.ajaxblender.com/open-links-new-window-w3c-valid-target-blank.html
NOTE: Although it is deprecated in XHTML 1.0 strict, target="_blank" been brought back in HTML 5.
Stydying your audience will help you decide on this. Casual websurfers will appreciate target=_blank while tech-savvy people are more likely to get annoyed.
As for XHTML 1.0 strict, it is never appropriate. The target-attribute is deprecated in XHTML 1.0 strict.
Never. If I want to open your link in a new window I will do so.
When you open the link in a new window.
There exists practice to open in new window links that refer another/external domain (wiki for example).
I use it for product brochures and the like as I think it is useful for the customer to stay on the product page. I always indicate [new window] next to the link to keep the customer informed. Often the product brochure is a PDF, so I also note that the link will open a PDF.
Use it as you need it, but keep your users informed so as not to annoy/confuse them.
I prefer to avoid it, because most users can figure out on their own how to open a link in a new window, even if unsophisticated. My preference is to use an explicitly named destination, e.g. target="somename" if you have a good reason for opening a new window on your own.
I only use it when the client insists.
Otherwise I prefer to let the user decide.
I might be in the minority here but I like using target="_blank" for my links ONLY when they're meant to be reference links. In most cases, you shouldn't be using it for regular links around a website.
I really don't like it when I click on a link in a blog post or an article and it loads on the same page and I need to navigate back to the original source page.
When you are creating an email for mobile users and are linking to external content. That way, when they click on the link they will open the page in their browser.
When you want to open any particular link in new tab on current window then you can use target="_blank" in html.
<div class="restrunt-menu-list">
<ul>
<li>
<span>
<a target="_blank" href="www.example.com">View Menu</a></span>
</li>
</ul>
</div>
But It might affect your system performance because all browsers takes a lot of memory when it open a new tab or new window.
So less opened tab means less memory uses, less memory uses means better performance.
You can also see that which tab using how mach memory in chrome:
Press shift+Esc , Then you can see Task Manager- Chrome with list currently using memory by each tabs ( in chorme ).
For all external links...
Here are some examples of what I mean:
google.com - focus is set on the "search" box
gmail.google.com - focus is set on the "user name" field (actually, most web email clients do this).
stackoverflow, ask a question - focus is set on the "title" box.
Sometimes, this is a convenient feature - e.g., on Google. From a usability standpoint, however, is it really considered a good feature to have on login pages?
Personally, I have often entered my user name, started to enter my password, then the page finished loading and had focus put back onto the user name field. Unfortunately, since I have complex passwords that force me to look at the keyboard while typing, I fail to notice when focus shifts. I often wind up typing my password in the unmasked user name field for anyone standing behind me to see.
Another situation, less dangerous but still annoying, is when I'm typing a url in my address bar while my homepage is still loading. As soon as it finishes, however, and if I'm not done entering the url, focus is stolen from me and put on some other field.
Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? Do problems like this bother ordinary (i.e., non-programmer) users?
These are really two separate questions with different answers:
Q: Should focus be given to the input field the user is most likely to use?
A: Most definitely yes, if "most users" really is 90% or more.
Q: Should this happen when the webpage finishes loading?
A: No. The "onLoad" event is a pretty stupid place to put this. The input field should get the focus as soon as it appears - it's usually completely irrelevant when the page finishes loading. Just put a <script> tag that sets the focus right after the input element itself.
I personally hate it when websites assume the focus. The main reason is that on my laptop, if I'm using the track pad and hit the backspace key it will automatically navigate back to the previous page. If focus has been placed on a textbox it will treat the backspace as tho I'm trying to delete a character.
My personal preference (and this has very little to do with best practice) is that it nothing should have initial focus, but the first tab will take it to the element that you want to have initial focus.
The same happened to me in Gmail, I find it slightly annoying, especially since it should be easy to circumvent:
In the OnLoad event handler, check if the input boxes (username or password) already contain text. If this is the case, do not change the focus.
As with all simple solutions, I would not be surprised if there were some strange side effects that render it unpractical, but I would give it a try anyway.
Oh, and if it works, why don't you send an email to Google? ;-)
That being said, I consider this behaviour a usability glitch, something that is not a bug, but slightly annoying. Don't annoy your customers. Fix it.
I think only we programmers have the habit of typing even before the page gets loaded ;-)
Most of the non-programmers friends I have wait till they see the "Completed" signal from the loading area.
But the 2 issues above are les annoying than having to move our mouse pointer/use tab everytime to type in what we want (username, password) in sites which do not have focus on a particular control.
"Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? "
I think browsers should be enabled to do this than the websites. Becauase it will be another trip back to server and can be frustrating for connections with low speed.
Overall I think this is just another minor issue/annoyance which we can live with. As I said only we programmers jump in type even before the page loads. Most of my friends dont know that they can type before the page gets loaded :)
There are sites where you acutally have one usecase a normal user uses keyboard for (normal user - as some, like me, use keyboard to navigate also). Sites like Google search actually expect you to just enter what you're looking for and hit enter.
Sites with multiple input areas and multiple exit paths though sometimes put initial focus somewhere too, and then it gets annoying. It gets even worse if they haev some odd tabbing order of their input areas - so they actually force you to use mouse.
I personally don't see the changing of focus when site finishes it's loading as an issue, not for a general user. But, as I mentioned, if it's really useful, it's a matter of what's the usecase in your particular application. And this might be a matter of showing the application in it's beta-stage to some people and performing usability tests.
Yes, focus should default to the most likely place for a user to start typing. Not doing so is textbook bad UI design.
When focus defaulting interferes with something you're already doing, this isn't an inherent problem of focus defaulting, it's a failure of an inadequate implementation. This, among other reasons, is why I put together a generic 'smart' autofocus script that does things like leaving you the hell alone if you've already started typing.
(Yes, I know it's hairy. Most of the hairiness is dealing with cross-browser issues -- a failing of Firefox, actually, for once.)