Oracle APEX – The Standard Component Attributes Anatomy Series: Read Only

As part of my ongoing preparation for an upcoming presentation on APEX items, I’m continuing the blog series that explores the fundamental, often underused capabilities of Oracle APEX.

In the first post, we looked at the Server-side Condition attribute and how it influences component behavior at runtime. Now, in this second post, we shift focus to another key attribute: Read-Only.

While it may seem straightforward, Read-Only in APEX is packed with flexibility and nuance. From static settings to conditional logic using PL/SQL or SQL expressions, understanding how this attribute works under the hood can help you build cleaner, more secure, and more maintainable applications.

Read Only

Very much like server-side conditions, the Read Only attribute in APEX also supports its own conditional logic. This allows you to control when a component—typically an item or region—should be rendered in a non-editable state, based on dynamic conditions.

Just like with server-side conditions, you can base this on item values, SQL queries, or PL/SQL expressions, giving you fine-grained control over when users can or cannot modify data.

Keep in mind that read-only conditions cascade: if a region is set to read-only, all items within it will also be read-only by default. The following example shows the default look and feel of read-only floating label templates in Universal Theme 24.2, with the read-only condition applied at the form level.

If you want a specific item—say a search field—to always remain editable regardless of the region’s read-only state, simply set that item’s Read Only Condition to “Never.” This effectively overrides the region setting and ensures the item stays editable.

Perhaps more interesting—and more important—is understanding what happens behind the scenes when the read-only attribute is set to true. Let’s break down the generated code to see exactly what’s happening at the item level.

<div class="t-Form-itemWrapper">
    <input 
        type="hidden"
        data-for="P3_JOB"
        value="Wdy9uFm1u3IG9An.....fRZrMefjsTTQevJoFWH7pjGkqpAX7K_OtOufMZHg">
    <input
        id="P3_JOB" 
        name="P3_JOB"
        class="js-accessible-readonly apex-item-text-readonly" 
        aria-readonly="true"
        spellcheck="false" 
        inputmode="none" 
        autocomplete="off" 
        value="CLERK" 
        size="32" />
</div>

Read-Only Attribute in APEX

A typical developer might expect Oracle APEX to use the standard HTML readonly attribute to make an item read-only. However, that’s not how APEX works.

Instead, Oracle APEX simulates read-only behavior using CSS and JavaScript, rather than relying on the native readonly attribute. Why? While we can’t say for certain, it seems APEX opts for a “fake read-only” approach for a few practical reasons:

• The input remains focusable, which benefits screen readers and allows users to copy values.

• Users can’t type into the field—it looks and acts read-only.

• The field's value is submitted with the form, unlike disabled inputs, which are ignored during submission.

This hybrid method gives APEX fine-grained control over the user experience while maintaining accessibility and functionality.

CSS Classes Used for Read-Only Items

Oracle APEX uses a combination of CSS classes to simulate read-only behavior, rather than relying on the native HTML readonly attribute. Two key classes are involved:

js-accessible-readonly
This class informs APEX’s JavaScript that the input should behave as read-only. Although users can’t modify the field, its value is still submitted with the form. It serves as a functional indicator rather than a visual one.

apex-item-text-readonly
This styling class handles the visual aspect. It makes the input look like a regular text field, but with a grayed-out or non-editable appearance to clearly signal that it’s read-only.

Together, these classes provide consistent behavior and appearance across different components, while maintaining accessibility and proper form submission.

If you're curious about the specific CSS properties applied to read-only items, you can explore them directly. Just open your browser’s developer tools or inspect the core.css file in your APEX installation's static files. Look for any of the following read-only-related classes (e.g., apex-item-autocomplete-readonly, apex-item-text-readonly, etc.) to see how APEX handles different item types in read-only mode.

ARIA Attribute

The aria-readonly attribute is used for accessibility. It tells screen readers and assistive technologies that an input is read-only—even if the standard HTML readonly attribute is not present. This helps maintain a consistent experience for all users.

Inputmode Attribute

As per the MDN Web Docs, the inputmode global attribute is an enumerated attribute that provides a hint about the type of data a user is expected to enter. This helps browsers display a context-appropriate virtual keyboard, particularly on mobile devices.

In the context of read-only fields, inputmode is sometimes set to none to discourage input.

Checksum

Perhaps the most important aspect of APEX's read-only mechanism is the hidden item generated alongside the read-only input. This hidden field stores a checksum value, which is submitted together with the original item.

During page processing, APEX uses this checksum to automatically validate that the value of the read-only item hasn't been tampered with by the user. If the checksum doesn't match, APEX raises a security error—ensuring data integrity for read-only items.

When Inputs Go Read-Only

Apart from the changes at the item attribute level, APEX also generates 'special' form items—such as date pickers, select lists, and popup LOVs—as input elements with their corresponding display values.

These components behave slightly differently when marked as read-only, often being rendered as plain text while still maintaining their functional styling. In all cases, APEX generates the necessary checksums behind the scenes to ensure data integrity and prevent tampering, just as it would for standard items.

Processing Read-Only Items

Last but not least, it’s worth mentioning the processing behavior of read-only forms or pages. When a page or region is marked as read-only, the backend processing remains unchanged. Validations will still run against read-only items just as they would for editable ones, and page processes—including custom PL/SQL processes—will continue to execute as expected.

You might assume that the Automatic Row Processing (DML) process would be skipped if the entire form region is rendered as read-only—but that’s not the case. APEX does not automatically disable processes based on the read-only state of a region or item. It’s up to the developer to implement any conditional logic to skip processing if needed.

That concludes everything I wanted to share about the read-only attribute in Oracle APEX.

Enjoy life!