Most test cases that manipulate a user interface are tightly tied to the current details of that UI. What the test case is doing often gets lost in the details of how it is doing it. We abstract away these implementation details by wrapping our application UI with a Physical Object Model that lets us reference the UI without having to know the details of how it is accessed.
We take this a step further by using a controls abstraction layer to smudge UI details into similarity. If a check box in the UI is changed to a radio button, everything that knows that check box is a check box now has to be updated to talk to it as a radio button. We don’t want to have to make that change, especially when a control simply changes to another type without affecting its semantics. If you really do care about a control’s type you can to talk to it as such, but we have found those occasions to be few and far between.