Hot answers tagged

27

No, it would seem not, as W3C states 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA) Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; Incidental: Text or images of text that are part of an ...


4

Assuming that we want to keep our UI as simple as possible and we do not want to overwhelm users with controls they can't use then the only reason to leave visible inaccessible features is to tempt users and make them engaged (to gain an account). If anonymous access is no more than a showcase (and you want it like that) then you don't have choice: leave ...


4

My short answer is no. Grey does not always represent disabled condition. I think it depends on the usage, context and the colour scheme of your app. Lets take email sign up popups as a first example. You land on some news website and immediately after the page loads you are presented with a popup with couple of inputs and usually two buttons, Cancel and ...


3

The best way would be not to use colour. In fact colour is not necessarily the best way to do it as it relies a lot on good eyesight (which designers usually have, don't forget). Here are some alternate ideas and ways of emphasising disabled state without using colour - these are suggestions, doing all would probably be overkill and observing users ...


2

Grey is a convention, not a rule It helps to understand why grey is used for disabled buttons: Grey is a neutral color so it's good for communicating subtle or de-emphasized elements. Disabled buttons (because they are not clickable) are usually communicated to the user via de-emphasis. The visual message is: "I am a button (look at my shape) but I ...


2

I think 3 is the best option here. 1 & 2 show the form fields and have them disabled, this could indicate to a user that they could become editable - and they may wonder if they need to perform an action to make them editable. Because they will never be editable, no form controls are needed. The data should be printed. Another thing they may help this ...


2

Disable "Sign Up" button, remove confirm email I think a better alternative to the options you provide would be to remove the confirm email box all together. There are a few reputable articles out there that make the case that they simply are not necessary. Why retype it if you can just read it? Only in 18% of the cases it was necessary to confirm the ...


2

Option 1. Hiding the content - You go to the tab, you see the explanation instead of the content, you got it. Simple as that. Hiding the content is better than disabling as disabling is usually used for business logic (for example, an option is disables unless some check-box is checked). Hiding the tab - The worst option. Users will get frustrated ...


2

Give users a reason to login or create an account. If getting and keeping people on board is important, making interaction easy and accessible will help to encourage them to become or stay active on your website. What should be accessible depends on the privacy and/or security policies of the website. Since you mentioned Facebook as an example take a look ...


1

Is there a reason to be coy about which domains are allowed? Why not prevent the user from inputing any other email from the start? Allow the user to select the domain. No chance for a wrong email. Remember that it's better to prevent an error than to give an error message and make the user redo work.


1

I'd like to share this article on "inactive" or "disabled" states: http://www.uxbooth.com/articles/who-killed-the-inactive-button-state/ Twitter, e.g., does not use the inactive-state at all - because it does not explain what actually is not going right. Instead of "You can not use me!", the message could be "You clicked me, yet I need THIS and THIS ...


1

Why would you not disable both? If you only disable the signup button, you'd have them enter an unusable email account twice? And you shouldn't enable the signup button until all the required fields have been filled. I'd suggest keeping it grayed out until enough fields have been filled, and then switch it to your brand color or something, to indicate they ...


1

Is it possible instead to just disable clicking after the first click and indicate to the user that something is now happening as a result of that first click by way of a cursor change or notification? This way the user knows that their initial click has indeed registered a response and they can't "stuff it up" by doing a second click. And the fact they ...


1

Consider just getting rid of save button. Whenever user makes a change, just remember that change and update it. And then give user a non-modal receipt like a toast. It's a common modern way of GUI implementation for Settings changes, especially for web based products. If you really want to have the save button, having one button makes more sense in your ...


1

Some thoughts: Speed – small checkboxes are not the best controls for the fast/frequent actions, according to Fitts's Law. It's too slow and exhausting to use chechboxes for the big data set Errors – placing checkboxes with different actions close to each other (Select and Disable) could cause errors (slips) while performing the action (e.g. clicking ...


1

To disable the option is a general way to go, is more appropriate considering that you should always work towards error prevention. My suggestion is to clearly change the appearance of the non-deletable node in comparison with the default ones, and additionally show a tooltip or something indicating why this node is special and cannot be deleted. Over time ...


1

The first option is the best. It's poor UX to invite someone to do something, and then tell them they can't do it. Think about Donald Norman's concept of 'Affordance'. A handle tells people that they can pull a door, while a plate tells them that they can push it. Your are giving people a handle on a push door here. Use a common pattern, like greying out ...


1

Short answer (and to avoid delving into how you are planning to parse content on your website) is yes it does - http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat.html If the Assistive Technology can't interpret your content correctly when Javascript is turned off on your page (or the web browser being used doesn't support Javascript) then it would not ...


1

I had a problem like this recently. The answer I came up with was this: Elements/controls must be contrast compliant when disabled as this provides vital clues to the user telling them that their task is incomplete or that certain options are selected/deselected. - In short: Yes, they need to be contrast compliant. EDIT - The following is incorrect however ...


1

I prefer 3. The reason is that if you have a couple of greyed out settings, displaying explantory text can become confusing or dazzling to inexperienced users. It is logical that they will try to tap the greyed out setting, in order to try turning it on. The nessecairy information will apear as needed, without overwhelming them. If you are concerned that ...


1

You might want to have a look at a related UXSE question. It is okay to use grey for non disabled things, provided there is no conflict on page. Currently your grey color is overloaded by two meanings. On buttons it acts as a disabled state, on icon is not the case. This reduces affordance and users would definitely frown upon it. The top answers in the ...


1

While designing some webpages, I came to this site to see what others had to say to make some decisions. I've concluded that the best answer is "it depends." I thought about my own experiences with enabled buttons that do nothing but tell me what I did wrong and, sometimes on a poorly designed webpage, clear everything! I especially find myself annoyed ...



Only top voted, non community-wiki answers of a minimum length are eligible