HTML Guides for dialog

The HTML specification defines a set of implicit ARIA roles (also called “native semantics”) for many HTML elements. The <dialog> element’s implicit role is dialog, which means assistive technologies like screen readers already announce it correctly without any explicit ARIA markup. When you add role="dialog" to a <dialog> element, you’re restating what the browser and accessibility tree already know—and the ARIA in HTML specification explicitly restricts this.

The ARIA in HTML spec maintains a list of allowed roles for each HTML element. For <dialog>, the only permitted role override is alertdialog (for dialogs that require an immediate response from the user). Setting role="dialog" is not listed as an allowed value because it duplicates the native semantics, and the spec treats such redundancy as a conformance error. This is why the W3C Validator reports: Bad value “dialog” for attribute “role” on element “dialog”.

Why this matters

• Standards compliance: The W3C Validator enforces the ARIA in HTML specification, which prohibits redundant role assignments on elements that already carry that role implicitly. Valid markup ensures your pages conform to web standards.
• Accessibility clarity: While most assistive technologies handle redundant roles gracefully today, unnecessary ARIA attributes add noise to the codebase and can cause confusion about whether the element’s native semantics are intentionally being overridden. The first rule of ARIA is: don’t use ARIA if a native HTML element already provides the semantics you need.
• Maintainability: Removing redundant attributes keeps your HTML clean and easier to maintain. Future developers won’t need to wonder whether the explicit role was added intentionally to work around a bug.

How to fix it

1. Locate any <dialog> element with a role="dialog" attribute.
2. Remove the role attribute entirely.
3. If you need the dialog to behave as an alert dialog (one that interrupts the user and demands immediate attention), use role="alertdialog" instead—this is the one permitted role override for <dialog>.

Examples

Incorrect — redundant role causes a validation error

<dialog role="dialog">
  <h2>Confirm action</h2>
  <p>Are you sure you want to proceed?</p>
  <button>Cancel</button>
  <button>Confirm</button>
</dialog>

Correct — relying on the implicit role

<dialog>
  <h2>Confirm action</h2>
  <p>Are you sure you want to proceed?</p>
  <button>Cancel</button>
  <button>Confirm</button>
</dialog>

The <dialog> element automatically exposes role="dialog" in the accessibility tree, so no explicit attribute is needed.

Correct — using an allowed role override

If the dialog represents an urgent alert that requires immediate user interaction, you can override the role with alertdialog:

<dialog role="alertdialog" aria-labelledby="alert-title" aria-describedby="alert-desc">
  <h2 id="alert-title">Session expiring</h2>
  <p id="alert-desc">Your session will expire in 60 seconds. Do you want to continue?</p>
  <button>Stay signed in</button>
</dialog>

This is valid because alertdialog is explicitly listed as a permitted role for the <dialog> element in the ARIA in HTML specification. Note that aria-labelledby and aria-describedby are strongly recommended for alert dialogs so assistive technologies can announce the title and description properly.

The <dialog> element was introduced to provide a native way to create modal and non-modal dialog boxes in HTML. As defined in the WHATWG HTML Living Standard and the ARIA in HTML specification, every <dialog> element automatically carries an implicit dialog role. This means assistive technologies like screen readers already recognize it as a dialog without any additional ARIA markup.

When you explicitly add role="dialog" to a <dialog> element, you’re restating what the browser and assistive technologies already know. This violates the first rule of ARIA use: do not use ARIA if you can use a native HTML element or attribute with the semantics already built in. While this redundancy won’t break functionality, it clutters your markup and signals to other developers (and validators) that the author may not understand the element’s built-in semantics.

This principle applies broadly across HTML. Many elements have implicit ARIA roles — <nav> has navigation, <main> has main, <button> has button, and so on. Adding the matching role explicitly to any of these elements produces a similar validator warning.

How to fix it

Simply remove the role="dialog" attribute from the <dialog> element. The built-in semantics handle everything automatically. If you need to provide additional context for assistive technologies, consider using aria-label or aria-labelledby to give the dialog a descriptive accessible name — that’s genuinely useful supplementary information rather than a redundant role.

Examples

Incorrect: redundant role attribute

<dialog role="dialog">
  <h2>Confirm action</h2>
  <p>Are you sure you want to delete this item?</p>
  <button>Cancel</button>
  <button>Delete</button>
</dialog>

This triggers the validator warning because role="dialog" duplicates the implicit role of the <dialog> element.

Correct: relying on implicit semantics

<dialog>
  <h2>Confirm action</h2>
  <p>Are you sure you want to delete this item?</p>
  <button>Cancel</button>
  <button>Delete</button>
</dialog>

Correct: adding a descriptive accessible name

<dialog aria-labelledby="dialog-title">
  <h2 id="dialog-title">Confirm action</h2>
  <p>Are you sure you want to delete this item?</p>
  <button>Cancel</button>
  <button>Delete</button>
</dialog>

Using aria-labelledby to associate the dialog with its heading is a meaningful enhancement — it gives the dialog an accessible name that screen readers announce when the dialog opens. This is the kind of ARIA usage that genuinely improves accessibility, as opposed to redundantly restating the element’s role.