WebElement State, Interactions, Forms, and Validation: Core Concepts and Mental Model

1. The command is not the outcome

Chapter 04 established how a locator produces a WebElement reference. Chapter 05 asks the next operational question: what does that element mean right now, and what should happen when a user-like interaction is applied? A located input can be present but hidden, visible but disabled, enabled but covered by another element, selected but invalid for the business rule, or replaced by a rerender after you captured its reference.

Reliable UI tests therefore separate three layers: element state, browser interaction semantics, and application outcome. A passing click() only proves that WebDriver completed the click command. It does not prove that inventory changed, a form was accepted, a confirmation appeared, or a release requirement was satisfied.

2. From locator to application outcome

flowchart TD
L[Locator] --> E[WebElement reference]
E --> S[Current element state]
S --> C[WebDriver interaction command]
C --> B[Browser event + default behavior]
B --> A[AUT state transition]
A --> O[Observable outcome]
O --> V[Assertion + evidence]

The locator selects a node. The WebElement is a protocol-backed reference to that node in one WebDriver session. State queries read the node as it exists now. Interaction commands ask the browser to perform user-like actions subject to WebDriver preconditions such as interactability. Browser events and native form behavior then drive the application. The final assertion should observe the state that expresses test intent.

This model also explains why stale references exist. If a framework rerenders the control and replaces the DOM node, the old WebElement still identifies the old node reference. The correct action is usually to reacquire the element from the current DOM, not to retry an obsolete reference blindly.

3. Presence, displayed, enabled, selected, and valid are different facts

The following table organizes the key choices and evidence for Presence, displayed, enabled, selected, and valid are different facts. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

These facts are intentionally independent. A checkbox can be displayed and enabled but not selected. A required email field can be displayed and enabled but invalid. A submit button can be enabled while a client-side validator later blocks submission. Treating “element exists” as a proxy for all other state collapses the evidence you need for diagnosis.

4. Attributes and runtime DOM properties are not interchangeable

HTML attributes are values declared in markup, such as value="seed" or checked. DOM properties are runtime JavaScript-facing values such as an input element’s current value or checked boolean. User input commonly changes the property without rewriting the original HTML attribute.

<input id="nickname" value="seed">
<input id="terms" type="checkbox" checked>

The following example makes the Attributes and runtime DOM properties are not interchangeable behavior concrete. Read it with the stated assumptions, then compare its observable output or state changes with the explanation that follows.

nickname = driver.find_element(By.ID, "nickname")
print("declared value attribute:", nickname.get_dom_attribute("value"))
print("runtime value property:", nickname.get_property("value"))

nickname.clear()
nickname.send_keys("Ada")
print("after typing, DOM attribute:", nickname.get_dom_attribute("value"))
print("after typing, property:", nickname.get_property("value"))

# get_attribute() is a convenience API: property first, then attribute.
print("convenience value:", nickname.get_attribute("value"))

5. WebDriver interaction commands are browser-mediated

Selenium documents a small set of high-level element interactions: click, send keys, clear, form submission behavior, and select-list support. These are deliberately closer to user behavior than assigning JavaScript properties directly. WebDriver may scroll an element into view and checks whether an element is interactable before performing an action.

A click targets the element center. If another element obscures that point, WebDriver can raise ElementClickInterceptedException. Sending keys requires a keyboard-interactable/editable target; an unsuitable element can produce invalid-element-state behavior. Those errors are valuable evidence because they tell you the browser could not perform the user action as modeled.

name = driver.find_element(By.ID, "name")
name.clear()
name.send_keys("Ava Example")

newsletter = driver.find_element(By.ID, "newsletter")
if not newsletter.is_selected():
    newsletter.click()

submit = driver.find_element(By.ID, "submit")
assert submit.is_displayed() and submit.is_enabled()
submit.click()

6. Form controls have semantics worth preserving

Checkboxes, radio buttons, text inputs, and native select lists are not generic clickable rectangles. Their browser semantics carry state and accessibility information. Use is_selected() for selection state, normal click for checkboxes/radios, and Selenium’s Select helper only for a real HTML <select>. A custom JavaScript dropdown made from <div> or <li> elements must be automated according to its actual DOM and interaction contract.

from selenium.webdriver.support.ui import Select

role = Select(driver.find_element(By.ID, "role"))
role.select_by_value("developer")
assert role.first_selected_option.get_attribute("value") == "developer"

terms = driver.find_element(By.ID, "terms")
assert not terms.is_selected()
terms.click()
assert terms.is_selected()

7. Inspect before mutation

Before changing form state, record enough read-only evidence to distinguish an environment problem from an interaction problem. The following inspection does not type, click, submit, or alter storage.

import selenium
from selenium.webdriver.common.by import By

print("selenium", selenium.__version__)
print("session", driver.session_id)
print("browser", driver.capabilities.get("browserName"), driver.capabilities.get("browserVersion"))
print("url", driver.current_url)
print("title", driver.title)

email = driver.find_element(By.ID, "email")
print("displayed", email.is_displayed())
print("enabled", email.is_enabled())
print("selected", email.is_selected())
print("declared-required", email.get_dom_attribute("required"))
print("runtime-value", email.get_property("value"))

If the wrong URL or fixture build is loaded, fix that boundary before changing element code. If the element is present but disabled or hidden, preserve that fact. If it is interactable but the application outcome is wrong, the failure belongs farther downstream in the model.

8. Production rule: assert the outcome, keep the state evidence

A durable browser test normally uses element-state assertions as preconditions and diagnostics, then asserts a meaningful application-visible result after interaction. This keeps failures precise without confusing “the button was enabled” with “the business operation succeeded.”

Knowledge check

Official references and version notes

• Selenium 4.47 release — current pinned Selenium release baseline for this chapter.
• Interacting with web elements — click, send keys, clear, interactability checks, and click-interception semantics.
• Information about web elements — displayed, enabled, selected, text, CSS, and attribute/property inspection.
• Python WebElement API 4.47.0 — current get_dom_attribute, get_property, get_attribute, interaction, and state-query APIs.
• Working with select list elements — current support-library semantics for real HTML <select> controls.