For displaying a readonly details views of a certain item on a website, is there a general rule to choose between disabled input fields or labels/plain text?

In this situation, first an overview of orders is shown, and users can click on a single order to see the details of that order. With an edit button they go to yet another screen on which they can edit the order.

Any advice on how to decide between these? Thanks!

Extra info: The details view is an aggregate of all the editable data. Via an edit button per "editable section", the user can navigate to a page where that section is editable with other input controls like autocompleters, treeviews, dropdownlist, ...

  • 1
    Note that disabled form elements are harder to read (cluttered, often lower contrast due to grey-out, generally ugly) than plain text.
    – Ben Brocka
    Dec 19, 2011 at 17:40
  • related question: ux.stackexchange.com/questions/12606/… Dec 21, 2011 at 0:46
  • @Naoise, note the difference though: I don't want to just change the fields to enabled state, I want to send them to another page using "other input controls like autocompleters etc"
    – koenmetsu
    Dec 21, 2011 at 7:58
  • 1
    In this case, if they are two different pages, I'd go with the "plain text" in the view page and active inputs in the edit page. Otherwise the user can get the wrong impression they can be edited in the view page. Dec 21, 2011 at 11:02

7 Answers 7


First, bear in mind that a label is not the same than plain text. A label "represents a caption for an item in a user interface", the item normally being a form input.

About if using disabled inputs or plain text, it depends on the workflow for editing the information:

  • If the edit form is one page away, have the information displayed as "plain text" in its own page.

  • If the edit form is in the same page, then disabled input fields would be better. The input fields would be activated by toggling an "edit" option.

In both cases, the way of displaying the information conveys the right message to the user: in the first, that "information can't be edited in this page", the second, that "the information can be edited, but you need to activate edition mode".

  • 1
    Could you tone down the bolding? When almost every other sentence is bolded, emphasis is lost altogether. Plus, it is distracting and hard on my ol' eyes. Dec 19, 2011 at 12:15
  • You really think so? I feel it emphasizes what you need to reed if you are just browsing around or are in a hurry. Dec 19, 2011 at 12:17
  • 1
    @NaoiseGolden It does help when you have one or two points bolded. When it's 4, it loses it's effectiveness by a lot. Dec 19, 2011 at 12:55
  • @NaoiseGolden: Yes, otherwise I wouldn't have made the comment... Dec 19, 2011 at 13:32

Use a text box that looks like a label when not editable, but like a typical text box when it is editable. This will allow you to use one control, but not look awkward when it is not editable.

enter image description here

  • The downside is that the user can't know that in some other state of the system, the "Non editable" text is actually editable. Dec 19, 2011 at 12:21
  • 1
    @HenrikEkblom But if a whole form is filler with these, and contains an "edit" button like the question says, then the user should instantly see every change to an editable state. Dec 19, 2011 at 12:25

I would say it depends on the situation and interface. Generally speaking, grayed-out fields can often times confuse users who are not computer savvy. Who is the user group? Additionally, if a field is grayed out but is editable, a clear "edit" hyperlink should be close to that field, in line of site so that there is a direct relationship and understanding of how to edit a field that is grayed-out. Depending on what is being edited, if it's a profile, such as a payment profile, then there would need to be a clear CTA (Call to Action) to edit those groups of fields, located in the top right of the group. Again, the layout, position of elements, and content being edited and the context can all influence what the real IA call would be. If you could provide a link to the layout or wire, perhaps that would help.

All the best, Arondale


General rule - if it's a text area that is sometimes editable, make it a disabled input field. For example, you have to select a country before you can type in your zip code. Before the country is selected, make the input field disabled. This gives the user a clue that "I can interact with this field, but not right now". You can use the disabled input fields in combination with mouse over tooltips that explains why it is disabled.

If it's never editable - make it plain text!

This follows the same convention as other web interactive objects, like buttons. If a button usually is enabled, but becomes disabled it tells the user "in this state of the environment, I can't press the button because the variables aren't set right" - for example, one of many required text fields aren't filled correctly.


Semantically, I believe the original intent of disabled form fields was for exactly this. It allows you to retain label/input pairings in read-only modes.

Alas, historically, browsers weren't really that great at rendering read-only form elements, and CSS was (and to an extent, still is) unable to fully style form elements so I think that this was a less-often used model of markup.

These days, however, if your browser can successfully handle appropriate styling, It's probably the better default option to go with.


One option would be to have all the un-edited text as labels, then when the user clicks the edit button, they all turn into editable text fields. I don't have much experience with web development, but my solution would require two separate webpage, and a lot of work.

Just an idea, hope it helps.


I think the answer for you lies within the question:

With an edit button they go to yet another screen on which they can edit the order.

Using a disabled input element suggests that this element can, somehow, be made editable. In your case, it can't. Essentially, you are suggesting that there is a form in read-only-mode. And modes are a very troublesome thing for users, since the same UI may or may not allow different actions depending on the mode the application is in.

The big problem is how to let the user know in which mode they are, and to tell them how they can change it. Because they will look for a way to get those disabled form elements into an editable state.

I could imagine your scenario working well if:

  • By default, the list would be presented as read-only form elements
  • there is a big "Edit" button
  • clicking the button enables all the form elements and replaces the edit button with a "save" and a "cancel" button

Or, better yet:

  • the list is presented as editable form elements right away

Because, why have the user actively invoke the edit mode in the first place? It's not like the edit mode conflicts with giving an overview.

One more scenario:

  • Like on flickr, display all elements as plain text. When an element is clicked, turn it into an editable form field. ESC cancels, enter confirms.

This is called a Quasimode – it is only active as long as the user explicitly invokes it (here by keeping focus on the form element). This makes it much easier for the user to understand whether they are in edit mode, and why. A practical example: No one keeps Shift (=Quasimode) pressed accidentally, but CapsLock (=Mode) is a constant source of annoyance.

However, it seems to me that your scenario is bound to the actual editing happening on another page entirely, so form elements are just confusing. A clean, nicely designed table is better suited.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.