Results / Ant Design

Ant Design dialog

91% against antd@6.6.0. Every check below cites the clause it measures, and every failure carries the command that reproduces it.

Reproduce this whole run

Serve the adapter from a clone of the repository, then:

npx @railing-dev/runner run --target antd --component dialog \
  --repeat 3 \
  --base-url http://localhost:5180

Or replay it without running anything: download the Playwright trace and open it with npx playwright show-trace.

The control that opens the dialog has an accessible name

Check: dialog.trigger-has-accessible-name
Status: pass
Severity: serious
Why it matters: A screen reader user hearing only "button" has no way to know what activating it will do.
Measured against: APG pattern · WCAG 4.1.2 Name, Role, Value

The trigger can be reached with the Tab key

Check: dialog.trigger-is-focusable
Status: pass
Severity: blocker
Why it matters: If Tab does not reach the trigger, a keyboard user cannot open the dialog at all.
Measured against: APG pattern · WCAG 2.1.1 Keyboard

Pressing Enter on the focused trigger opens the dialog

Check: dialog.opens-on-enter
Status: pass
Severity: blocker
Why it matters: Mouse users can open it; if Enter does nothing, keyboard users are locked out of whatever the dialog contains.
Measured against: APG pattern · WCAG 2.1.1 Keyboard

The dialog exposes role=dialog or role=alertdialog

Check: dialog.has-dialog-role
Status: pass
Severity: serious
Why it matters: The role is what tells assistive technology this is a dialog, enabling its dialog-specific behaviour and announcements.
Measured against: APG pattern · WCAG 4.1.2 Name, Role, Value

The dialog has an accessible name

Check: dialog.has-accessible-name
Status: pass
Severity: serious
Why it matters: On opening, a screen reader announces the dialog's name. Without one the user is told only that a dialog opened, with no indication of what it is for.
Measured against: APG pattern · WCAG 4.1.2 Name, Role, Value

Focus moves into the dialog when it opens

Check: dialog.focus-moves-in
Status: pass
Severity: blocker
Why it matters: If focus stays behind on the page, a keyboard or screen reader user has no idea the dialog appeared and must hunt for it.
Measured against: APG pattern · WCAG 2.4.3 Focus Order

Tab never reaches operable content behind the dialog

Check: dialog.focus-trapped-forward
Status: pass
Severity: blocker
Why it matters: Content behind a modal is inert to a mouse user. If Tab escapes into it, a keyboard user ends up interacting with things they cannot see.
Measured against: APG pattern · WCAG 2.4.3 Focus Order

Shift+Tab never reaches operable content behind the dialog

Check: dialog.focus-trapped-backward
Status: pass
Severity: blocker
Why it matters: Backward traversal is routinely forgotten when forward traversal is handled, and it strands users just as badly.
Measured against: APG pattern · WCAG 2.4.3 Focus Order

Focus left the dialog after 4 Tab presses.

Check

dialog.tab-never-leaves-dialog

Status

fail

Severity

moderate

Why it matters

A tab stop on nothing gives a keyboard user no feedback and no way to tell whether they have fallen out of the dialog. They have not, and can carry on, which is why this is not a blocker, but the APG asks Tab to cycle among the dialog's own elements.

Expected

focus stays on the dialog's own elements throughout the cycle

Measured

<body> (nothing focused)

Measured against

APG pattern · WCAG 2.4.3 Focus Order

Reproduce

npx @railing-dev/runner run --target antd --component dialog \
  --only dialog.tab-never-leaves-dialog \
  --base-url http://localhost:5180

Escape closes the dialog

Check: dialog.escape-closes
Status: pass
Severity: serious
Why it matters: Escape is the universally learned way out of a modal. Without it, a user who cannot find the close button is stuck.
Measured against: APG pattern · WCAG 2.1.2 No Keyboard Trap

Closing the dialog returns focus to the trigger

Check: dialog.focus-restored-on-close
Status: pass
Severity: serious
Why it matters: If focus is dropped to the top of the document on close, the user loses their place and has to tab back through the whole page.
Measured against: APG pattern · WCAG 2.4.3 Focus Order

Background content is still exposed to assistive technology while the modal is open.

Check

dialog.background-inert

Status

fail

Severity

serious

Why it matters

A modal is visually exclusive. If the page behind it is still in the accessibility tree, a screen reader user can read and operate content that a sighted user cannot reach.

Expected

hr-outside-content hidden from the accessibility tree (aria-hidden, inert, or equivalent)

Measured

hr-outside-content still present and not ignored

Measured against

APG pattern · WCAG 4.1.2 Name, Role, Value

Reproduce

npx @railing-dev/runner run --target antd --component dialog \
  --only dialog.background-inert \
  --base-url http://localhost:5180

The close control has an accessible name

Check: dialog.close-has-accessible-name
Status: pass
Severity: moderate
Why it matters: Close buttons are frequently icon-only. Without a name, the way out of the dialog is announced as an unlabelled button.
Measured against: APG pattern · WCAG 4.1.2 Name, Role, Value

What this cannot tell you

A high score means no violations were detected by automated testing. It does not mean the component is accessible. Automated tests cannot judge whether a label is meaningful, whether a reading order makes sense, or whether the experience is usable with a screen reader. Those need human judgement and disabled users. This is a floor, not a ceiling.