Read Only

What is Read Only?

In modern web development, controlling user input is fundamental to building interactive and secure forms. The readonly attribute and :read-only CSS pseudo-class provide developers with powerful tools to create read-only form fields that display information without allowing modification.

Understanding these mechanisms is essential for creating professional web applications that balance user experience with data integrity. This guide explores the HTML readonly attribute, the CSS :read-only pseudo-class, and the JavaScript techniques for manipulating read-only state.

The read-only state represents a form control that displays a value but prevents user modification. Unlike disabled controls, read-only fields remain focusable and participate in form submission, making them ideal for displaying information that users should see but not edit.

Constraint Validation and Form Submission

When the readonly attribute is present on an input element, the element does not participate in constraint validation. This means that validation constraints such as required, minlength, maxlength, and pattern matching are effectively ignored for readonly fields according to MDN's documentation on the readonly attribute.

The rationale is straightforward: if users cannot modify the field, requiring them to provide valid input is impossible. Therefore, combining readonly with required has no practical effect and should be avoided.

Read-only form controls behave identically to editable controls during form submission. Their values are included in the submitted data, allowing server-side processing to access the readonly field's contents. This behavior distinguishes readonly from disabled controls, which are explicitly excluded from form submission.

For robust form validation strategies, always implement server-side checks regardless of client-side readonly states.

JavaScript and Readonly State

JavaScript provides two primary methods for manipulating readonly state: setting the DOM property and setting the HTML attribute.

Setting Readonly State

The distinction between setting the property and setting the attribute is important. Setting the property (element.readOnly = true) is generally more efficient and immediate. The attribute approach is useful when you need to serialize the state or work with frameworks that track attribute changes.

Checking Readonly State

// Check via property (recommended)
if (input.readOnly) {
 console.log('Field is read-only');
}

// Check via attribute
if (input.hasAttribute('readonly')) {
 console.log('Field has readonly attribute');
}

// Toggle readonly state
function toggleReadonly(element) {
 element.readOnly = !element.readOnly;
 updateVisualState(element);
}

Common Patterns

Dynamic Form Scenarios: Toggle readonly state based on form progression, such as locking fields after form submission or multi-step form wizards.

Profile Editor: Allow users to switch between view and edit modes with appropriate visual feedback and smooth transitions between states.

Generated Values: Display values computed or set programmatically that users should not modify, such as auto-generated coupon codes or system timestamps.

Performance Considerations

For forms with many readonly fields, batch updates to minimize layout reflows. Setting readOnly on large numbers of inputs can trigger layout recalculations, so consider using document fragments or batch processing techniques for optimal performance.

These JavaScript techniques are essential for building dynamic web applications with responsive form interactions.

Readonly vs Disabled: Key Differences

Understanding the distinction between readonly and disabled is crucial for proper form implementation:

When to Use Each

Use readonly when:

• Displaying information for review without modification
• The value is essential for form submission
• Users need to copy content from the field
• The field should remain focusable for accessibility

Use disabled when:

• The field is temporarily unavailable
• The value should not be submitted
• Visual indication of unavailability is needed
• The field will be enabled based on other interactions

Security Considerations

Neither readonly nor disabled provides security. Users can modify these attributes using browser developer tools, potentially bypassing intended restrictions. Any security-critical validation must occur on the server-side, not relying on client-side readonly or disabled states as documented in research by Adrian Roselli.

When building secure web applications, always implement server-side validation regardless of client-side state.

Accessibility Considerations

Screen Reader Behavior

Screen reader support for readonly states varies significantly across combinations of browsers and screen readers. Research shows inconsistent announcements:

• JAWS with Chrome: Announces readonly for text, email, number, password, search, telephone, and URL inputs
• NVDA with Firefox: Announces readonly for text, email, month, password, search, telephone, URL, and week inputs
• VoiceOver macOS: Announces as "selectable" rather than read-only
• TalkBack with Chrome: Announces as "disabled" rather than read-only according to research by Adrian Roselli

This inconsistency means developers cannot rely on screen readers to consistently communicate readonly state to users.

Styling Challenges

The lack of default browser styling for readonly controls creates challenges:

1. No visual indication - Users may not realize a field is readonly without trying to edit it
2. Inconsistent browser behavior - Firefox applies gray text to date/time inputs; Chrome on Android extends this to month/week inputs as documented by Adrian Roselli
3. Contrast requirements - WCAG guidelines mandate sufficient contrast for read-only text

Best Practices

• Provide clear visual indicators (borders, colors, icons) to communicate readonly state
• Consider alternative patterns for complex readonly scenarios, such as displaying values as plain text
• Use ARIA judiciously with aria-readonly="true" can help but may not be consistently announced
• Test with actual assistive technology combinations your users actually employ

Security Note

Neither readonly nor disabled provides security. Users can modify these attributes using browser developer tools. Server-side validation is essential regardless of client-side state.

Creating accessible web experiences requires careful attention to how readonly states are communicated to all users.

Use Cases and Examples

Confirmation Forms

Readonly fields excel in scenarios where users review and confirm information before final submission. Display shipping details, order summaries, or profile information that users can see but not modify.

Profile Display Modes

Toggle between edit and view modes, allowing users to switch between readonly display and editable fields with appropriate visual feedback and smooth transitions.

Generated Values

Display values that are computed or set programmatically, such as system-generated IDs, timestamps, calculated totals, or auto-generated coupon codes that users should not modify directly.

Order Summary Displays

Show order details, pricing breakdowns, and total calculations in readonly fields during checkout review steps to prevent accidental modifications while maintaining clear visibility of all values.

These patterns are essential for building professional web forms that guide users through complex interactions.

Best Practices Summary

Do's

• Use readonly for values users should review but not modify
• Apply clear visual styling to indicate readonly state
• Test with real assistive technology combinations
• Implement server-side validation regardless of client-side state
• Keep readonly fields focusable for accessibility navigation

Don'ts

• Rely on readonly for security-critical data
• Combine readonly with required (it's meaningless)
• Assume consistent screen reader behavior
• Forget to test keyboard navigation
• Use readonly as the only form of data protection

Common Patterns

1. Review and Confirm: Display values in readonly fields during review before submission
2. Read-Only Display: Show computed or system-generated values
3. Toggle Edit: Allow switching between readonly view and editable mode with appropriate visual feedback

Browser Compatibility

The readonly attribute and :read-only pseudo-class have excellent browser support across all modern browsers. Minor differences exist in styling date/time inputs in readonly state, particularly between Firefox and Chrome on different platforms.