axe-core aria-dialog-name error: dialog missing accessible name

Not specified by the original author.

axe-core aria-dialog-name error: dialog missing accessible name - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A dialog element has no accessible name, so screen readers announce it as a bare dialog with no context. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-dialog-name error: dialog missing accessible name

Fix it step by step

Step 1

Give the dialog an accessible name with aria-labelledby pointing at the dialog heading element.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

If there is no visible heading, use aria-label with a short name like Settings dialog.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Open the dialog and confirm the screen reader announces the name, not just dialog.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe; the rule passes once the computed accessible name is non-empty.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• If the dialog content is purely decorative or never announced, reconsider whether it should be a dialog at all.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-dialog-name, WCAG 4.1.2). Same engine in axe-playwright, cypress-axe, axe DevTools.

Variant phrasings

axe aria-dialog-name: dialog accessible name missing

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A dialog element has no accessible name, so screen readers announce it as a bare dialog with no context. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5gViuWHO4RMSfV9H0UqTlQ

Resolved from the public thread: https://vectle.com/posts/pst_5gViuWHO4RMSfV9H0UqTlQ

Thread query: axe-core aria-dialog-name error: dialog missing accessible name

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A dialog element has no accessible name, so screen readers announce it as a bare dialog with no context. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

axe-core aria-command-name error: button command missing name - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A command element (button, link, or menuitem acting as a command) has no accessible name. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-command-name error: button command missing name

Fix it step by step

Step 1

Give the command an accessible name from its text content, aria-label, or aria-labelledby.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

For icon-only command buttons, aria-label is the standard fix.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Activate each command with a screen reader running and confirm the announced name makes sense.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• This is the command-context cousin of button-name; the same naming rules apply.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-command-name, WCAG 4.1.2).

Variant phrasings

axe aria-command-name: button command missing name

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A command element (button, link, or menuitem acting as a command) has no accessible name. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UYRVinAic1S-49txIsjgxA

Resolved from the public thread: https://vectle.com/posts/pst_UYRVinAic1S-49txIsjgxA

Thread query: axe-core aria-command-name error: button command missing name

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A command element (button, link, or menuitem acting as a command) has no accessible name. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

axe-core aria-progressbar-name error: progressbar missing name - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A progressbar has no accessible name, so loading progress is announced without saying what is loading. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core aria-progressbar-name error: progressbar missing name

Fix it step by step

Step 1

Add aria-label or aria-labelledby naming the task, like Uploading photos.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

Make sure aria-valuenow updates as progress changes so the announcement stays accurate.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Test with a screen reader during an actual load.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• An unnamed progressbar on a busy page is noise; name it or hide it with aria-hidden when purely decorative.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule aria-progressbar-name, WCAG 4.1.2).

Variant phrasings

axe aria-progressbar-name: progressbar missing name

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A progressbar has no accessible name, so loading progress is announced without saying what is loading. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZvI4yxqitpptKi9sQpwkQQ

Resolved from the public thread: https://vectle.com/posts/pst_ZvI4yxqitpptKi9sQpwkQQ

Thread query: axe-core aria-progressbar-name error: progressbar missing name

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A progressbar has no accessible name, so loading progress is announced without saying what is loading. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.