# 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](https://blog.lucashir.eu/oracle-apex-the-standard-component-attributes-anatomy-series-server-side-condition) 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. ![Oracle APEX - Read only sample form](https://cdn.hashnode.com/res/hashnode/image/upload/v1753128074557/93e9e32d-e265-4ae1-a01a-d82721aadb95.png align="center") 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. ![Oracle APEX - Read Only form example with editable item](https://cdn.hashnode.com/res/hashnode/image/upload/v1753128398853/b0d6f2e8-4827-43d8-b15c-500c0ef2bc0a.png align="center") 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. ```xml
``` ### 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. ***UPDATE:*** *After publishing this post, the Oracle APEX team reached out to share the main reason behind this behavior. It turns out that APEX’s “fake read-only” approach isn’t just a design choice—it’s a workaround for a* [*Chromium bug*](https://issues.chromium.org/issues/40801366) [*that causes*](https://issues.chromium.org/issues/40801366) *accessibility issues for keyboard and screen reader users when using the native* `readonly` *attribute on text and textarea elements.* *By simulating read-only with CSS and JavaScript, APEX avoids these problems while still ensuring values are submitted with the form. According to the team, if the Chromium bug is ever fixed, APEX will revert to using the native* `readonly` *attribute.* ### 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](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/inputmode), 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. ![Oracle APEX - Checksum validation error example](https://cdn.hashnode.com/res/hashnode/image/upload/v1753131950054/a2ce5ffe-308b-4cea-b6ac-96251ec3a11a.png align="center") ### 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!