Digital Hall of Fame ARIA-Readonly Audit for Inductee Record Grids

What aria-readonly Does — and When an Inductee Grid Needs It

aria-readonly is an ARIA state property that communicates whether the value of an interactive element can be changed by the user. Its two valid values are "true" (read-only: focus and read, but not edit) and "false" (editable: the default for interactive elements that accept input).

The attribute belongs only on elements that carry roles where editing is conceptually possible: gridcell, columnheader (inside a grid), rowheader (inside a grid), combobox, listbox, radiogroup, slider, spinbutton, and textbox. Of these, the gridcell role is the most relevant to a digital hall of fame inductee roster, because the ARIA grid pattern is the correct semantic structure for an interactive table where users navigate cells with arrow keys and can potentially activate inline actions.

For a screen reader user navigating a role="grid", encountering a role="gridcell" raises the expectation that the cell might be editable—the same mental model applies to spreadsheets and data management interfaces where grids are used precisely because they support editing. When a hall of fame inductee record grid uses this pattern but does not permit editing of inductee fields, aria-readonly="true" removes that ambiguity: the screen reader announces the cell as read-only, and the user does not waste time attempting to activate an editor that will never appear.

When a plain HTML table is used instead of an ARIA grid, aria-readonly is not needed. A <td> element carries the cell role, which does not support the aria-readonly property. Screen readers treat plain table cells as inherently non-editable. Adding aria-readonly="true" to a <td> is technically valid HTML but conveys nothing meaningful and may mislead future maintainers. The audit’s first task is to distinguish which inductee displays use a role="grid" pattern and which use a plain <table> — and to apply the attribute only where the grid role is present.

The compliance anchor is WCAG 2.1 SC 4.1.2 (Name, Role, Value, Level AA): the read-only state of an interactive grid cell is a programmatically determinable property, and failing to expose it is a Level AA failure on any grid that contains a mix of editable and non-editable cells.

Decision Table: When aria-readonly Is Required on an Inductee Display

Use this table to determine whether aria-readonly applies to each element type in a hall of fame inductee display.

This table captures the most common patterns found during a digital hall of fame aria readonly audit. When in doubt, ask: does this element carry a role that conceptually supports editing? If no, aria-readonly adds no value. If yes, and the element cannot be edited in the current context, aria-readonly="true" is required.

How to Run a Digital Hall of Fame ARIA-Readonly Audit

Step 1 — Identify Whether the Inductee Display Uses a Grid Pattern or a Plain Table

Open the hall of fame interface in Chrome or Edge. Open DevTools (F12) and in the Console tab run:

Array.from(document.querySelectorAll('[role="grid"], [role="treegrid"]')).map(el => ({
  role: el.getAttribute('role'),
  id: el.id || '(none)',
  ariaReadonly: el.getAttribute('aria-readonly') || '(absent)',
  cellCount: el.querySelectorAll('[role="gridcell"]').length
}))

If this query returns an empty array, the inductee display uses plain <table> markup and aria-readonly is not applicable — the audit is complete for this view. Document this result: the absence of a grid role is not a failure; it is correct semantic HTML.

If the query returns one or more grid containers, proceed to Step 2.

Step 2 — Inventory All gridcell Elements and Their aria-readonly State

For each grid container identified in Step 1, run the following query to retrieve every gridcell and its current aria-readonly value:

Array.from(document.querySelectorAll('[role="gridcell"]')).map(el => ({
  text: el.textContent.trim().slice(0, 60),
  ariaReadonly: el.getAttribute('aria-readonly') || '(absent)',
  ariaDisabled: el.getAttribute('aria-disabled') || '(absent)',
  tabindex: el.getAttribute('tabindex'),
  parentGridReadonly: el.closest('[role="grid"]')?.getAttribute('aria-readonly') || '(absent)'
}))

Record every cell where ariaReadonly is '(absent)' and parentGridReadonly is also '(absent)'. These cells carry no aria-readonly signal. Whether they are a finding depends on whether they should be editable — which Step 3 determines.

Step 3 — Determine Which Cells Are Intended to Be Non-Editable

Activate each gridcell in the grid by pressing Enter or Space while keyboard focus is on the cell. For each cell, observe whether:

• An inline text editor, date picker, or input field appears (the cell is editable)
• Nothing happens except visual focus state (the cell is non-editable)
• A link or button activates to open a profile view (the cell is a navigation target, not an editor)

Cells where no inline editor appears and no input is possible are non-editable. If those cells carry no aria-readonly attribute at the cell or container level, flag them as findings.

Cells that open an inline editor should not carry aria-readonly="true". If a cell that opens an editor has aria-readonly="true" set — perhaps as a misconfigured default — flag it as a separate finding: the state misrepresents the cell’s actual behavior.

Step 4 — Test the Screen Reader Announcement for Read-Only State

Install NVDA (Windows, free) or activate VoiceOver (macOS, built-in). Navigate to the hall of fame inductee grid using Tab, then use arrow keys to move among cells.

For each non-editable gridcell that correctly carries aria-readonly="true", the screen reader should announce a read-only indicator as part of the cell description. Common announcement patterns:

• NVDA: “Inductee Name, Rivera M., read only”
• VoiceOver: “Rivera M., read only”

If the screen reader announces a cell without any read-only indicator, and the cell’s aria-readonly="true" is correctly set in the DOM, the announcement may be suppressed by a conflicting ARIA attribute or by an overriding CSS that removes the element from the accessibility tree. Check for aria-hidden="true" on the cell or any ancestor.

If the screen reader implies the cell is editable — by announcing it the same way an editable textbox or input would be announced — aria-readonly="true" is likely absent or incorrectly placed on a child element rather than on the gridcell itself.

Step 5 — Check Container-Level Inheritance

If the audit in Step 2 found that the grid container carries aria-readonly="true", verify that individual editable cells correctly override it with aria-readonly="false". Run:

const grid = document.querySelector('[role="grid"][aria-readonly="true"]');
if (grid) {
  Array.from(grid.querySelectorAll('[role="gridcell"][aria-readonly="false"]')).map(el => ({
    text: el.textContent.trim().slice(0, 60),
    cellReadonly: el.getAttribute('aria-readonly')
  }))
}

Any editable cell that does not appear in this output — while its grid container carries aria-readonly="true" — will inherit the container’s read-only state and will be incorrectly announced as read-only even though the user can edit it. Flag each such cell.

Step 6 — Audit Each View That Renders a Grid

If the platform renders inductee grids on more than one route — a full roster view, a filtered sport view, a search results view, and a profile detail view — run Steps 1 through 5 independently in each view. Different route templates may use different grid implementations. A read-only state correctly implemented on the main roster grid may be absent from the grid rendered in the filtered sport view.

Common Failure Patterns on Hall of Fame Platforms

Pattern 1: aria-readonly absent from all gridcells in a display-only grid. The platform uses role="grid" and role="gridcell" to build the inductee roster — the grid pattern was selected to support keyboard navigation — but the grid is entirely non-editable. No aria-readonly is set at the container level or on any cell. Screen reader users navigate into cells and receive no indication that editing is not possible. The fix is to add aria-readonly="true" to the role="grid" container, which propagates to all cells without requiring per-cell markup.

Pattern 2: aria-readonly added to plain <td> elements unnecessarily. A developer auditing the platform added aria-readonly="true" to every <td> in a plain HTML table, mistakenly applying the ARIA grid pattern’s requirements to a non-grid table. The attribute has no effect on <td> elements and does not cause accessibility failures, but it introduces maintenance confusion and signals a misunderstanding of when the attribute applies. Remove it and document the distinction for the development team.

Pattern 3: aria-readonly set on a child element inside the gridcell, not on the gridcell itself. A <span> inside a role="gridcell" carries aria-readonly="true". The <span> is not the element that exposes the gridcell role to the accessibility tree, so the read-only state is not associated with the cell. Screen readers do not announce the cell as read-only. The attribute must be placed directly on the element with role="gridcell", not on its children.

Pattern 4: aria-readonly=“true” on an editable cell. During initial accessibility remediation, a developer applied aria-readonly="true" to all cells in a mixed grid, including the cells that support inline editing of award descriptions or induction years. An authorized administrator who activates one of those cells can still edit it — the HTML contenteditable or underlying input is not controlled by aria-readonly — but the screen reader announces the cell as read-only, causing the administrator to believe editing is impossible. The fix is to remove aria-readonly from cells that accept input, or to dynamically set aria-readonly="false" when an edit session begins.

Pattern 5: aria-readonly not updated when a grid transitions between view and edit modes. Some hall of fame platforms allow authorized users to switch the entire inductee grid between a view-only mode and an edit mode. When the mode switches, the visual interface updates but the aria-readonly state on the grid cells does not. Screen reader users operating in edit mode are still told cells are read-only. A dynamic mode switch must update aria-readonly on affected cells — or on the container — at the same time it updates the visual presentation.

The same discipline that governs read-only state on these grids applies to how the grid communicates column identities in virtualized rendering. Guidance on that related pattern is covered in the digital hall of fame aria-colindex audit for virtualized inductee tables, which addresses how ARIA column indexing keeps cell semantics accurate when rows are recycled during scroll.

aria-readonly vs. aria-disabled: Choosing the Right State

On an inductee record grid, aria-readonly and aria-disabled are both used to communicate that a cell cannot be changed — but they convey different states to assistive technology, and choosing the wrong one creates the wrong expectation.

For the vast majority of inductee record data — name, sport, graduation year, award description — aria-readonly="true" is the correct choice. The visitor needs to navigate to those cells and read their content. aria-disabled would imply the cell has no function, which is incorrect: the cell’s function is to present a record that the visitor came to read.

The toggle controls that filter or sort the grid — if they use a pressed state — are a related but separate concern covered in the digital hall of fame aria-pressed audit for toggle controls, which addresses how sport-filter and decade-filter toggles communicate their active state independently of the grid cells they affect.

Practical School Recognition Examples

Athletics hall of fame inductee roster grid. A school builds its hall of fame roster using role="grid" because the athletics coordinator needs to navigate cells with arrow keys during record verification. The inductee name, sport, graduation year, and award tier are all display-only fields. aria-readonly="true" is placed on the role="grid" container. When screen reader users browse the grid during an athletics banquet event, every cell is correctly announced as read-only, and no visitor attempts to edit a field that the public-facing interface does not permit modifying.

Mixed grid with editable award descriptions. A school’s recognition platform gives authorized staff an inline editor for updating the award citation text on each inductee record, while all other fields — name, year, sport — remain locked. The role="grid" container carries no aria-readonly. Each locked role="gridcell" (name, year, sport) carries aria-readonly="true". Each citation role="gridcell" carries aria-readonly="false". When an administrator logs in and navigates to the grid, the screen reader announces locked cells as “read only” and the citation cell without that qualifier, correctly communicating where editing is possible.

Touchscreen kiosk with a display-only grid. A kiosk in the school lobby renders the same inductee roster as the web interface but uses a simplified ARIA grid for keyboard-accessible navigation via a connected switch device. All cells are display-only. The kiosk template places aria-readonly="true" on the role="grid" container. A student using a switch controller navigates through the inductee records during a recognition ceremony and hears each cell announced with its content and read-only state — confirming the record is informational without requiring a screen reader mode switch to understand why no editor appears.

Search results grid. After a visitor searches for inductees by sport, the platform renders a filtered role="grid" of matching records. The search results grid is generated by a different component than the main roster grid. During the audit, this grid’s cells are found to have no aria-readonly attribute, even though the main roster grid correctly uses the container-level setting. Because the search results grid is a separate template, the container-level attribute must be added independently. The audit flags this as a Tier 1 finding for the search results route.

The search controls that feed data into these grids — including the aria-labelledby associations that give each filter its accessible name — are addressed in the digital hall of fame aria-labelledby audit for inductee search controls, which covers how search input fields and their labels must be programmatically linked for screen reader users to understand what each control does.

Each deployment context for a hall of fame platform — desktop web, mobile web, and physical kiosk — may render the inductee grid using a different component or template. The aria-readonly setting must be verified in each context independently. A container-level aria-readonly="true" correctly applied on the desktop web template does not guarantee the mobile template or kiosk template inherits the same setting.

When a grid transitions into a loading state — for example, while a sport filter is applied and new records are being fetched — the grid may temporarily disable interaction. The correct attribute during loading is aria-busy="true" on the grid container rather than a change to aria-readonly state. Guidance on the busy state during data loading is covered in the digital hall of fame aria-busy audit, which addresses how to correctly signal that a grid is loading new records without implying the records themselves have changed their editability.

Connecting This Audit to Broader Accessibility Work

A digital hall of fame aria readonly audit for inductee record grids belongs in a broader accessibility review alongside companion audits that address the full interactive grid experience.

Pair with an aria-colindex audit. When an inductee record grid uses virtualization — rendering only the visible rows in the DOM and recycling row elements as the visitor scrolls — column index attributes must be applied correctly so screen readers can identify which column each cell belongs to. The digital hall of fame aria-colindex audit for virtualized inductee tables addresses the column indexing requirements that accompany the same grid pattern where aria-readonly applies.

Pair with an aria-selected audit. In a hall of fame interface that uses tabs to filter by era, sport, or award type — where each tab activates a different view of the inductee grid — the selected tab must expose its active state via aria-selected. The digital hall of fame aria-selected audit for tabs and filter results covers how to verify that tab selection state is programmatically determinable, which is a precondition for the grid beneath the tabs to present the correct data to the screen reader user who navigated by tab.

Pair with a keyboard navigation audit. The aria-readonly="true" attribute tells screen readers a cell is non-editable, but it does not substitute for verifying that the grid’s keyboard navigation is functional. Every role="gridcell" must be reachable by arrow key from within the grid, and activating a read-only cell by pressing Enter should not trigger an editor or produce an error. The keyboard navigation audit confirms that the physical interaction model matches the accessibility state that aria-readonly describes.

Pair with a focus management audit. When a visitor activates a cell in the grid and an action occurs — a profile modal opens, a sort state changes, a filter applies — focus must be managed so the screen reader user knows where they are after the interaction. A cell carrying aria-readonly="true" that navigates away from the grid on activation requires focus to land on a logical next target. Without correct focus management, the aria-readonly state is correct but the interaction is still inaccessible.

Remediation Priority Framework

When bringing aria-readonly findings to a platform vendor, organize them in three tiers:

Tier 1 — aria-readonly absent from a display-only ARIA grid. A role="grid" that carries no aria-readonly on the container or on any of its cells, where no cells accept inline editing, is a Level AA failure under SC 4.1.2. Every screen reader user navigating the grid receives no signal about read-only state. Remediation is a single attribute addition to the grid container.

Tier 2 — aria-readonly=“true” on editable cells. A cell that accepts inline editing but carries aria-readonly="true" misrepresents its state. An authorized administrator using a screen reader cannot discover that the cell is editable. Remediation requires identifying which cells accept input and removing or correcting the attribute — a per-cell change that may require template inspection.

Tier 3 — aria-readonly inconsistent across deployment contexts. The main roster grid correctly exposes the read-only state but the search results grid, filtered view grid, or kiosk template does not. The state is correctly implemented in one template but not propagated to all templates that render the same underlying data. Remediation is a template normalization task.

Tier 1 findings should be treated as decision factors in platform procurement. A recognition platform that uses an ARIA grid pattern for its inductee roster but does not expose read-only state on any of its cells has a foundational gap in its accessibility implementation — one that affects every visitor using assistive technology on every page that renders the inductee grid.

Quick-Reference Audit Checklist

Discovery

• DevTools query run on main roster view, search results view, filtered sport view, and kiosk template
• Presence of role="grid" confirmed or absence documented (plain <table> = no action required)
• All role="gridcell" elements inventoried with aria-readonly value and parent container aria-readonly value

Read-Only State Verification

• All display-only cells confirmed to carry aria-readonly="true" (cell-level or inherited from container)
• All editable cells confirmed to carry aria-readonly="false" or no aria-readonly attribute
• Container-level aria-readonly="true" confirmed present where all cells are non-editable
• No aria-readonly found on plain <td> elements (unnecessary attribute)

Screen Reader Test

• NVDA or VoiceOver active; each role="gridcell" navigated to by arrow key
• Read-only cells announced with “read only” or equivalent in screen reader output
• Editable cells announced without “read only” qualifier
• Mixed grid: editable and non-editable cells distinguished correctly in announcements

Mode-Switch Verification (if applicable)

• Grid correctly updates aria-readonly when platform transitions between view-only and edit mode
• After mode switch, screen reader correctly announces updated state on affected cells

State Conflicts

• No cells carry both aria-readonly="true" and aria-disabled="true"
• Cells that are display-only use aria-readonly, not aria-disabled
• Loading states use aria-busy, not changes to aria-readonly

Documentation

• Each finding categorized as Tier 1 (absent from display-only grid), Tier 2 (set on editable cell), or Tier 3 (inconsistent across templates)
• Remediation request structured with grid location, current attribute state, expected state, and reproduction steps
• Re-test scheduled within 30 days of vendor remediation delivery

Rocket Alumni Solutions builds correct aria-readonly implementation into the inductee record grid at the component level — display-only grids carry the attribute on the container so every cell inherits the read-only state without per-cell repetition, mixed grids apply the attribute cell-by-cell so editable fields are clearly distinguished, and the attribute updates correctly when administrators switch between view and edit modes. Schools that want to confirm their current display exposes read-only state accurately — or that are evaluating a new hall of fame platform for an accessible recognition installation — can walk through the grid implementation during a personalized demo.

Written by the Team

Experts in digital hall of fame solutions, helping schools and organizations honor their legacy.

Rocket Alumni Solutions