Related
TIL that screen reader users rarely use tabs for navigating web pages and instead use specific keyboard shortcuts from their screen reader software (e.g. CTRL + OPTION + Arrow Keys in VoiceOver). This would mean that optimizing for tabbable navigation does not always make sense.
However I've seen some web pages adding tabindex="-1" to their headline elements or for elements that are not directly viewable due to overflow: scroll.
So my question would be: When does it make sense to optimize for tab navigation and when doesn't it?
E.g. in our current use case we've created a questionnaire that basically shows a question (h2 element) that can be answered with 2-5 answers (button elements). Clicking the answer will lead to a new page with the next question. When activating VoiceOver it seems like a good idea to have the question element set to tabindex="-1" and auto-focussed when the question is opened. But the learning above seems to challenge this a bit.
Thanks for your help!
So first of all you are confusing tabbing with focus. While a screen reader user may use arrow key navigation, they may also bring up a list of links on the page, or forms, regions, tables or (most often) headings in order to navigate to sections that interest them / get a feel for the page layout.
Tabbing is useful as there are plenty of people who cannot, struggle or prefer not to use a mouse but do not require the assistance of a screen reader i.e. Cerebral Palsy due to accuracy issues.
Hopefully that clears that bit up for you.
As for autofocusing an input on a multi-page form, that is more of a UX issue...is it good UX for all users if you auto-focus the form.
I would say yes, requiring people to click, tab or use shortcuts to get to the input if that is going to be the action that 99% of people need to take is not good UX.
Notice I say the <input> and not the heading.
What you do want to do is look into how to indicate this is a multi-page and multi-step form on the first page of the process.
You should also consider having a checkbox as the first step that says something like "this form is multi-page, would you like us to auto-focus the first question when a new page is loaded" and have it default to checked.
That way someone has the choice to stop the auto focus if they wish.
Additionally (or as an alternative if you do not want the checkbox) you may consider adding some text near to the submit button (and properly associate it with aria-labelledby and an ID) that explains that the next step loads a new page and the first input will be auto focused.
Another thing is that assuming you have titled the pages correctly (Form name or process - step 2 of 5) then a screen reader user can easily ensure they are on the correct page.
So focus the input if this is a multi page form, not the heading level 1.
Focusing headings after navigation is a trick for Single Page Applications (SPAs) so that might be where you have seen that, if you load the page content via AJAX then that is one of the recommended ways to handle navigation. You indicated next page "loads" which makes me think this is a Multi Page Application, but I thought I better add that just in case as a general tip.
Bear in mind that all of this advice is general. Depending on your form, site design, loading pattern, user base (experienced users / internal system vs general public) etc. the best practice may be different.
So long answer short - use autofocus on the input if this is a multi step form and you think it is appropriate and obvious that the input would be the next thing to fill in.
Then test it with someone who uses a screen reader and get feedback as to whether it makes sense or if it was confusing or unexpected.
You are making a confusion between screen reader user and keyboard user.
One doesn't necessarily implies the other.
People having dyslexia but normal sight may use a screen reader so that they can hear a text out loud instead of trying hard to read it themselves, but since they otherwise use a mouse or a touch interface, they aren't keyboard users.
People having difficulties using their hands but with a normal sight might not be able to use a mouse or a touch interface.
They don't need a screen reader, but use exclusively a keyboard or maybe another specific input device that mimique the most important keys of a keyboard (in particular, tab, arrow keys, enter and escape).
A joystick in some form can be such a device.
Considering what has been said above, designing a proper keyboard navigation and optimizing it always make sense. It may not be of important use for some screen reader users, but it's very important for keyboard users, as it's maybe their only way for them to interact with the app/page.
I am a screen reader user. With others, I believe a confusion about input focus is being associated with structural and contextual concerns. To the first question regarding when to “optimize” TAB experiences. It is always important since keyboard navigation is a supporting pillar used in my toolbox as a screen reader user. In addition, any input based non-screen reader accessibility tool is likely going to use this means of access.
As a developer, a guideline I always impress on other is the fact you want the natural structure and flow of code to do most of the work for you. Secondly, the process should follow expectations of your target audience and it seems you want to follow a “wizard” style. So, let me spell out a typical expectation for a wizard style questionnaire flow when using a screen reader.
UX point: does page reload fully or dynamically change?
This matters as this has a direct impact on my current reader “cursor” and how I will navigate to find the question.
From above statements, I will assume H2 will be used consistently. Thus, I will naturally use quick navigation to go to the first H2.
Now, I will use screen reader tools to read the question (be it TTS or braille output).
Once I feel I have its meaning, I will typically use TAB to find the first input control. Buttons are not input controls and thus violates user expectations. I am looking for checkbox, radio box, text field, and/or combo box.
If check or radio boxes, then I am assuming a group and hope for grouping (sadly rarely present) and will use tactics to deal with the situation I have found. If grouped, then I am using TABs a lot to move quickly and hear the “context” of the specific box focused with input.
Finally once I have answered the question, I am looking for the next question or forward/previous mechanism. These typically show up as buttons.
Hopefully, I am demonstrating how conventions/expectation are built using basic structure rather than trying to force procedure on the user. Thirdly, sites like a11y project can be very helpful with coding.
So over the past couple of weeks I've been working on trying to create a way of using google forms as a kind of editable pdf. The idea is to have it be used as a group work order wherein the various people involved fill out the information pertaining to them as they acquire it. Now I know this isn't exactly what forms are designed to do, but it seems to mostly be working.
The way I have it right now is that the initial user creates the initial response, which triggers a script on the form submission, that sends out an editable link via email to all of the contributors to the form. Then whenever a contributor has information to add, they merely have to follow the link, make the change, submit the form and another email gets sent off alerting everyone of the edit.
The only problem with the system, however, comes when two users are filling out the edit link at the same time. At that point the collision resolution (or potentially a lack of collision resolution) for the edit link appears to kick in. The first user will submit and the form gets updated correctly, but once the second user submits, their changes override the changes of the first user. Looking at this from a user standpoint this would be highly confusing. Their change would appear to have been registered correctly, but in reality have been overwritten and discarded.
Now the ideal solution would be that the only changes that are overridden by the second user are those that actually have values in them. I.e. if user one answers question A, and user two answers question B, and both answer question C, only question C is actually overridden, instead of A and C.
I initially thought that perhaps I could compare the two form responses and find some way of doing the collision detection on my own, but there seems to be no way to edit the actual form responses, to change the data on the edit link to match. (Changing the spreadsheet values does not actually have any impact on the edit link itself)
So my question really boils down to is there a way to get this collision detection to work the way I am intending it to? And if there isn't any way to do that, what would be the best way to trigger off a warning email when a collision does happen so that the users would at least know that something went wrong?
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.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 11 days ago.
Improve this question
I usually add the "clear form" button to HTML forms by default. Is this button actually necessary or a holdover from another time? I have never gotten to the end of the form and thought "I screwed up, I need to reset this!".
I stopped adding those about 1997. It really bothers me when I fill out a large form and accidentially hit the Clear button. I am not really sure why they were ever used in the first place. You're right, I don't think I've ever filled out a form and said to myself, "Oh wait a minute, I think I want to start over?"
The nice thing about the reset button is that it will repopulate all form elements with their original values, not simply set them to zero or blank. So if the form was generated by server with saved data, the user makes a bunch of changes, and then realizes not only that something is wrong but that they also have no clue what the original value was, reset is VERY handy.
Also it's nice for forms with lots of numerical data, like the timesheet page I'm working on right now. There are potentially 16 fields, all with generic, somewhat meaningless numbers. If the user figures out they were looking at the wrong schedule, it's nice to just nuke it back to what the server loaded.
Having said all of that, my page does NOT include a reset button, simply because I didn't want to leave open the exact opposite of awesome it presents, which is "and I'll just click this button to save...oh shit."
What I do instead is any field can be set to 0, but any non-valid data (non-numeric, less than 0, greater than 16) will revert back to the value last entered (which is stored via js). Doesn't offer the grand sweep, but it at least lowers the amount of possible data entry errors and keeps the user from losing data over a simple mistake.
456 has a great article and link on this topic, by the way.
No, we don't need it. I usually just hit the Refresh button.
And then remember it's a #$#$## Flash website.
In what situation would you enter totally wrong information for 10+ fields before realizing it? And then, how much time does it save to clear them before starting over instead of just changing each value? It's adding a major UI element that is not only completely useless, but dangerous for 99.99% of your users so the remaining .01% saves maybe 1 second of their time.
What about one day you need to use it ?
I guess nowadays maybe there are some issues with browsers autofilling forms
for you with irrelevant information that people might want to clear.
I think instead of clearing the whole form, selecting some of them and pressing clear button would be something users would want more.
Anthony's example seems to be the only valid reason why we would add a "clear" button on forms now-a-days. It only seems relevant within a web application of some sort. I don't think general single-direction-forms will benefit much, such as collecting personal information. I couldn't tell you the the last... or for that matter, the first time I ever used a "clear" button as a USER. I can certainly give examples to when I used it as a developer, but that was before Firefox became so awesome!
So; in the end... I think it's more traditional than functional. Unless you've got a complex web application, I see no need for this extra functionality.
I often have a select box that has an "add new >>" option, whereupon the select field morphs into a text field to allow users to add new values to the field on-the-fly. I put a reset button so they can get the regular select box back.
In order to avoid the usability issue of accidentally clicking reset when they meant to click submit I put it some distance away from submit and have it in a neutral tone while the submit button is an accented color (sorta like OS X, it's got the glowing blue button and then the grey ones.)
However, I still don't really like it. I've been exploring a reset button of some sort on each select box that morphs so they can just reset that one piece.
Hmm, maybe your average IE and Firefox users may not be aware that there is a supposed "feature" called autocomplete that these browsers offer by default.
Maybe the "clear form" button is commonly provided for forms due to the chance the user has not unchecked the Remember search forms and history and the Form & Search History checkboxes, and will otherwise be confused and try to manually delete form fields...
EDIT --
And apparently there is a non-W3C-standard attribute autocomplete that can be added to input fields of a form and set to "off." There may be problems with this though, check out this stackoverflow question about it.
Just a thought to the people who can't think of any reason to have a reset form button! We have a search form at the top of our results pages, which is pre-filled with the search criteria from the previous search. Without a reset form button, the user has to either go back to the previous page, or manually clear all the form fields to do a new search. Why pre-fill the search form? So the user can keep the rest of their search parameters the same and change the location they're searching in, for example.
Edit: I just found out the reset button returns all form values to their original values. So, I'm talking more about a "clear all fields" button really.
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.)