Good question. I have personally considered this and have watched dogmatic colleagues struggle with a notion of strict adherence to methodology.
My answer is: It is a balance. This is true, especially in Front-End Systems and most UI. Here is why:
In C, C++, and Java Object-Oriented methodology is a best-practice because the three tenets of OO can be defined clearly in code. That is to say, Inheritance, Polymorphism, and Abstraction improve maintenance, reuse, and extensibility.
Enter JavaScript and we have opened a can of worms. This is because JavaScript can be more expressive without the three tenets. This is for a myriad of reasons but the prime one being JS is object-oriented with objects only; no classes. So there is a simplification in practice.
Attempting to force classical inheritance into that environment, in short, can result in added complexity, not reduced complexity. Designing constructs such as private members can be added maintenance.
That said, let me answer your questions in succession:
Is the choice an object?
-> It can be, but it depends. Should it be reusable? Can it contain behavior or other member variables? In JavaScript, it is an object... always. So this is potentially something of minimal concern.
Is it truly object-oriented?
My perspective is that this is boils down to a matter of opinion, how 'true' the methodology is implemented. There is, perhaps, always a way to refactor something to more closely match a paradigm. So again, to me, this can potentially be of minimal concern. I'll explain why in a moment.
Is the question wrong, and is there another approach?
Correct sir. There are other approaches. Object-Oriented Design is a good idea when it is a good fit with implementation. If you are writing your GUI interface in Qt C++, then by all means, yes it is a good fit. In Java, yes, inherit. However, if you are following a new Windows 8 Metro JavaScript approach, there are a number of topics for consideration.
Another approach.
My suggestion for consideration would be for Design Patterns. Why? Because they are a set of designed patterns to commonly solved problems. The notable achievement here is that this knowledge is highly transferable across language. Implementation is then follows suit of the pattern.
Design Pattern Example.
So, as an alternative to applying scrutiny on implementation, one can take a step back and review the overall design. For example, not-is it truly object oriented, but- do we desire a master-detail pattern, a double-list, or.. etc.
By defining the Design Pattern, implementation becomes self-evident. Sometimes it will be pure Object-Oriented Design, sometimes it will be a higher level Design Pattern.
Thus, it is a balance of implementation in practice and design methodology.
Here is a link, and link.
My humble advice is to understand the 3 tenets, the Design Patterns, and then to flexibly craft the best-fit (maintainable, reusable, extensible, etc.) into each given environment.