From a User Interface design point of view when is it better to disable a control or to completely hide it. I have attached an example. In both case if the "Enable ASP.NET" checkbox is clicked the "Select. Net Version selector is enabled.
I would argue that it's almost always best to just disable. Hiding controls means you're leaving a portion of your functionality/configurability a mystery to the end-user. Unless there's a compelling reason to keep users in the dark, I wouldn't.
Your example of a checkbox that enables/disables or hides/unhides a dropdown box is a good one. If users aren't aware that checking the box allows them to select further options, they may never check it and find out, because they don't realize the option they're looking for is there.
Many of us, as developers, come from the "try everything" mindset when it comes to using a piece of software. Normal users don't think that way, and that's not a bad thing, either. It just means we have to keep in mind that not everybody will do what it takes to discover a piece of UI that's been hidden. Leaving it visible but disabled lets them see that there's something there for the having should they decide they want/need to use it, rather than leaving them either wondering if the software does something or never even considering that it might.
This really depends on the context of the example. In this case there is some value associated with disabling the control as it provides a visual affordance that enabling the ASP .Net checkbox will have a determinable outcome.
If the outcome of the checkbox is actually a whole series of non related suboptions or the parent control was a dropdownlist which determines which child elements become available then it would be better to hide / show only those elements that are appropriate to the current selection.
One other point, if you are describing "hiding" the controls as control.visible = false in code rather than display:none then remember that the output will actually not be rendered into the browser at all. This may be a concern if you are catering for disabled users with browsers requiring stricter accessibility requirements etc.
To me that depends on user knowledge. If the user knows what should follow I tend to give them as much information as possible so I would show it disabled. If the user is clueless as to what follows I hide as much as possible. Sometimes I do different things on user role and sometimes it depends on the average user of the application and their expected understanding of the underlying issues.
hth,
\ ^ / i l l
I prefer to disabled the control, so the user can see that he may have something to fill out. But it can be usefull to hide it if you are restricted on space.
It really depends on the situation
Related
Is it ok in regards to accessibility to scroll content into view? Is it disorienting for some users to have the page move by itself?
For instance, if a dropdown opens and only a few options are visible, is it better to let the user scroll the whole dropdown into view or to do this programmatically?
Scrolling into view seems like a nice UX improvement (we're avoiding an extra action from the user) but also possibly important accessibility-wise (the user might not realize there is important content below the fold, so we're making sure they see it).
On the other hand, moving the whole page seems like it could be jarring to some user, who may lose track of where they are on the page...
Good question. There may be some that benefit from it, but others will definitely find it disorientating.
Without knowing more about the actual case, I would default to not auto-scrolling, because auto-animation requires a number of other things to be in place.
There are some WCAG rules which only apply when there is automatic movement. (e.g. https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide)
Also the fact there's a CSS media query to accommodate this kind of thing shows that this is a feature that some users will prefer to avoid.
If you're using a CSS transition to handle this, it should be quite easy to put it in a prefers-reduced-motion media query, and the browser preferences would offer a mechanism to switch off the feature, making it compliant with SC 2.2.2
Even if you're doing the scrolling entirely with javaScript, you can still access the media query.
As an alternative, or even as an additional hint (belt and braces), you might consider adding a visual affordance to the last visible item indicating "more...". I have seen this handled with an ellipsis, or downward-pointing triangle/caret, but those idioms aren't strongly established for this kind of thing.
Screen reader users may be at a small advantage here. If you've marked up your popup correctly, the AT will announce the number of items, visible or not. :)
Good luck!
WCAG's definition of functionality
processes and outcomes achievable through user action
link to source
Following WCAG's definition for "functionality", it seems intuitive that just as functional elements should always be keyboard focusable, non-functional elements should not.
However, in accessibility matter, naïve intuition can be misleading. As I could not find any definitive guidelines or failure criteria for this on W3C site, I'm asking here:
Is it ever a good practice to make a non-functional element keyboard focusable?
If there are W3C or other official standards supporting your answer, please mention them.
Note 1: Please do not provide scrollable but otherwise non-interactive elements as an example - for our purpose, scrolling is an interaction.
Note 2: Somewhat related, but not a duplicate of the question "Should text ever be focusable for accessibility? I'm specifically thinking about key-value pairs", also somewhat similar to this question: "Accesibility vs. read only inputs", but that was asked in 2013, and its single answer isn't authoritative enough IMO (and I'm guessing is incorrect for today's accessibility conventions).
Is it ever a good practice to make a non-functional element keyboard focusable?
Yes, but in very rare circumstances.
Oh, you want a longer answer? 😋
Tab panels are a prime example (and the only concrete example I can think of) of when tabindex="0" is useful.
In this instance it serves no purpose other than to allow a user to easily navigate to the panel so they can read it's contents.
This is demonstrated and explained on the W3 Example of manual tab activation page.
The reason this is suggested is that it functions in a similar fashion to a "skip link".
All the tabs are operable with the arrow keys, but the whole tab list is one tab stop.
Then when a user has opened the tab they want to read they can press Tab in order to jump to the content instead of having to read out the rest of the tab options.
Some "fluffy" examples
The only other time I have seen this used and it felt correct is in a "live chat" application when you could Alt + Tab through the conversation items. This felt better than using headings, sections or other ways we may make something keyboard navigable (and arrow keys didn't feel intuitive).
One last one that comes to mind would be data tables, sometimes you may want a table to receive focus so that a user can navigate by arrow keys. So it receives focus to activate the component and let people know it is interactive via keyboard.
I am thinking of someone not using assistive tech but who uses the keyboard due to mobility impairments in this instance.
However that is just speculation I have never implemented that myself and if I did it would probably be because a highlighted row changes a graph etc. (which I am sure you would count as interactive!)
Any official guidance?
With regards to official guidance, I doubt you will find something concrete. Obviously WCAG 2.4.3 - Focus Order does come into play here as adding a tabindex="0" to everything is not a "logical focus order", but it will not give you a definitive answer as it has to allow for custom components etc.
I am afraid this one is a "best practices" rather than a rules scenario. You would probably still pass WCAG if every item on the page had a tabindex="0" as WCAG doesn't focus on user experience but rather on whether something can be used at all. However nobody who relies on assistive tech would want to use the page with a hundred tabindex="0"!
If you adopt the principle that the focus should always be visible, then situations can exist in which the only way to make that be true is to put a non-interactive element into focus. A skip-navigation link needs a destination after the navigation header, but it is possible that nothing in the main region is interactive. A modal dialog, when dismissed, needs to have a focal successor, but its dismissal may cause the triggering element to disappear and leave no other element, or at least no intuitively reasonable successor element, interactive.
Another scenario: A user action could cause informative messages (hints, clues, annotations, etc.) to be inserted at various points throught a view. They might all be in live regions, but that would not make them easy to locate. Making them focusable would allow the user to navigate through them sequentially, ensuring that none of them is missed and no laborious searching is required.
I've seen a few error dialogs implemented this way, where the only interactive element on the dialog was the OK button, and they decided to set tabindex="0" on the message text.
This meant they could put focus on the OK button when the dialog opened, for faster dismissal, yet allow screen reader users to tab to the message text. This was probably more common before we had role="dialog". Overall I would say that making a noninteractive element focusable should be situational and rare. Don't do anything that would confuse users. But if it results in something that's intuitive and easier to use, I would say go for it.
Can some one please tell me if I should use user controls in my project as much as I can? Ff so why and if not why not?
It's an interesting question; but think of it this way.
You've just written a table, listing all of your users. You show this on the List Users page of your website.
On the "Find User" page, you might want to be able to show a list of users. Do you rewrite the same HTML, code, javascript, CSS as before? Or do you reuse the control, this time adding the ability to filter by a user name or other attributes?
Essentially, user controls are there to package up reusable bits of your website. Rather than repeating the same code everywhere, you can package it up in a user control, and simply add it to any page you want just by adding the appropriate tag.
Also, you have just made ONE control in your project responsible for dealing with some functionality - all of the logic for it is in one place and separated from other code. This is an important concept too, as it stops all of your code being jumbled together. In the users example, you can interact with a list of users through an interface, rather than mixing it with other code that might do different things. This is called SRP and can be a good thing.
As a practical example, we have a control that shows a list of our products. We can reuse the same control on the Find screen, the Admin screen, the "Products Like this" screen, and on the "Products you have chosen" screen. This code contains a lot of logic that is all in one place so it can be maintained easily, and it can be reused very simply too.
User Controls can be a very good thing. So you should use them when you feel like you can package up a group of existing controls, HTML etc. It makes them reusable, and much easier to maintain.
There is also the concept of custom controls - these are usually reimplementations of existing controls - you might have an ExtendedTextBox, for example, that validates the text as someone types it.
You can read more about both kinds of controls here
User controls are good for the same reasons that subroutines/functions/methods are good: code (and markup) re-use.
Like subroutines, controls can be a problem if they do things like modify global state, make lots of DB or other off-box calls that aren't always needed, introduce unavoidable synchronous blocking, etc. They can also add an unnecessary layer of complexity if they are never re-used.
I would use the controls that the VS IDE Toolbox provides as much as possible. I would only roll my own control if something that the environment supplied, didn't quite do what I wanted it to do.
Especially Ctrl+I , which is "mail this page". I'm using wordpress self hosted. So far I've found this code, not sure how to implement it or if it's old.
Please no plethora of reasons as to why you find this attempt pointless.
Really, shouldn't answer, but:
There's no reason for this, because there's always a very easy way around it. It'll probably take a lot more work than whatever you end up with's worth. If somebody has half of a computer literate mind, they probably can get past this without a problem at all.
Summary:
Don't bother
Disabling hotkeys won't stop anyone from just selecting that option from the File menu.
People will always find ways around these kinds of hacks. Turning off JavaScript, hacking the source with Firebug, Option+Click on a Mac, taking a screenshot, etc. They are completely ineffective against anyone even slightly determined to do what you don't want them to do.
You can't really do that. See this page for really good information on the portability of various key events in JavaScript across multiple browsers. You will see for one that each browser handles/responds to various key events in many different ways.
Also, most of the default browser actions (e.g. Ctrl-F, Ctrl-S) cannot be canceled if you are capturing key events. You can still detect some of them and respond, but you can't actually stop the browser from displaying the search dialog or whatever specific action is to be performed by the key combination.
Also, if someone really wants to take your page's HTML/JavaScript code or content, these methods won't stop them. The disable right click code from the link you referenced can prevent right click, but all someone has to do is disable javascript and it no longer works.
I'm also interested in more general thoughts, but here is my specific problem. In an ASP.NET web app, I am connecting to a 3rd-party via API. The 3rd-party requires that the user login and answer a few configuration questions to set this up. All of the questions except one the user can just choose the default. On one question if the user chooses the default option, my app won't work with the 3rd-party. It is a limitation of their API. It is on their list to fix, but who knows when or if they actually will?
So what is the most effective way to give the user instructions in my app that they will follow once they go to this other site? Right now I have a screenshot with the option circled in red, follow by some descriptive text. What other techniques have you used in a similar situation?
Red text is the default mechanic in UI design to indicate importance (which is why it's used for errors so often).
Asterisks are the default choice for indicating required input.
Avoid flashing, and other garish-looking visual mechanics.
If this extends beyond a one-time inquiry, you should look at reading some good GUI books, like Don't Make Me Think: A Common Sense Approach to Web Usability and Designing Web Usability, both seminal books in the field.
I think you're headed in the right direction. I would make sure that your illustrative screenshot is large and easy to see the relevant details on. Also, some highlighted (classic yellow background ala 37 signals?) text to emphasize the importance of NOT selecting the offending option would be helpful.
Also, make this screenshot and highlighted instruction text, the VERY last thing they see before you forward them to or present the 3rd party site. Maybe make the action link (button, link, etc.) explicitly outline their acknowledgment of the thing not to do.
Maybe even, have fun with the caption like...
"I understand that choosing the default option above won't work."
Just some thoughts.
Unfortunately, nothing you can do will prevent idiots from choosing the wrong thing anyway. Basically, you can't make it idiot-proof.
This is more for GUIs but (depending on how critical this is) you can force users to type "I will choose xyz" before a redirect.
Is there a way to set a default on your end to get around this problem altogether? For example, picking some random setting initially that they could change in a profile of some kind that you can store on your end.
I've typically seen a red asterik(*) used for marking required fields on web forms if you want to not pre-select some value for the user for another way to try to solve this issue.
I know you want abstract, generalizations but there is no one true answer for what you're asking. I mean, what kind of content are we dealing with? Is the content broken up over multiple pages (or should it)? What kind of users generally use the form?
I know I've dealt with similar problems in dozens of different ways. Ideally you want not start treating your users as complete retards straight out of the box (just move to that progressively as they fail tasks), but you also want to be clear on what's going on.
The really high level (and obvious) ideal is that you want to make the instructions stand out to your punters. Colour change and standard icons do this (often poorly). However, changing the background colour of instruction text (to say a light gray) with a large icon (like a yellow sign with an exclamation mark) tends to focus the eye.
Another idea in your situation is to break the content in two. This might be done physically (press next to continue) or you might just colour code that hole part of the element a different colour to notify the user that they need to treat this differently.