Web accessibility checkers, checklists and references

Esc

Aria Hidden Checker

Paste HTML to list every aria-hidden attribute and see which ones hide focusable controls, visible text or the whole page.

Open on Accessible Web Kit

Embed

Embed this tool

Copy this code into your website, blog or class page. The tool runs inside your page.

Please keep the credit link below the tool.

The aria-hidden checker is a free tool that reads HTML you paste into it and lists every aria-hidden attribute it finds, with the value and any problems. aria-hidden is an ARIA attribute that removes an element and everything inside it from the accessibility tree, so screen readers skip it. The tool runs entirely in your browser, and nothing you paste is uploaded. It flags errors such as aria-hidden=“true” on the body element, focusable controls hidden from screen readers, and invalid values like “yes”. Use it to check a snippet before it goes into a page. It only sees the HTML you paste, so it cannot check CSS from a style sheet or scripts that change the page later.
Aria hidden example

How to use the aria-hidden checker

  1. Paste your HTML into the box labelled HTML to check. To try the tool first, click one of the three example buttons: Dialog backdrop, Decorative icons or Common mistakes. Each loads a sample snippet.
  2. Look at the results table. It has one row for each element that carries an aria-hidden attribute, showing its value and its findings.
  3. Read each finding. Errors mark markup that breaks accessibility rules and should be fixed. Warnings mark things to check against what you intended.
  4. Edit your HTML in the source and paste the new version into the box to check it again. Click Clear to empty the box and start over. Paste fresh HTML as often as you like: the table updates a moment after you stop typing.
  5. Run the Dialog backdrop example first if you want to see a clean result: its background is hidden and marked inert, so no error is listed. Common mistakes shows the error and warning messages.

When you are done, Copy result copies a plain-text list of the findings, which is useful for notes or a bug report. Copy link copies the address of this page. Short snippets are stored in the link, so the link reopens the same HTML.

What does aria-hidden do

aria-hidden=“true” removes an element and all of its descendants from the accessibility tree, so screen readers do not announce them. It does not hide anything visually, and it does not stop a keyboard user from moving focus to it. That gap is the source of most aria-hidden mistakes.

Because the attribute acts on everything inside the element, the rules follow from that scope. Visible text inside an aria-hidden=“true” element will not be heard by screen reader users, so the checker warns about it. Decorative elements such as svg icons and empty i elements produce no warning, because hiding them loses no information. A common use is an icon inside a button that already has text, where the icon would otherwise be read out again.

Focusable content is the most serious case. A link with an href, an enabled button or input, or any element with tabindex 0 or higher can receive keyboard focus. If it sits inside an aria-hidden=“true” element, a keyboard user can reach something a screen reader cannot see. To fix this, either remove the element from the Tab order with tabindex="-1" or the inert attribute, or do not hide the element at all. Note that tabindex="-1" only removes an element from the Tab order. It can still receive focus from a click or from script, so it is not a full fix for content that must stay unreachable.

Should I use aria-hidden on a modal background

When a modal dialog opens, the content behind it should not be read or reached while the dialog is open. Putting aria-hidden=“true” on the page behind the dialog is the usual pattern, and the Dialog backdrop example shows it. The background must also be taken out of the Tab order, with the inert attribute for example, or keyboard users can still tab into the page behind the dialog.

If you use a native dialog opened with showModal(), or set the inert attribute on the background, the browser already makes the rest of the page inert. In that case you do not need to add aria-hidden for the same purpose. The checker cannot see whether a script adds inert or calls showModal() after the page loads, so check that part in your code.

Frequently asked questions

aria-hidden true or false?

aria-hidden=“true” hides the element and its contents from screen readers. aria-hidden=“false” does not hide anything; it only repeats the default, so you can remove it. Inside an aria-hidden=“true” ancestor, aria-hidden=“false” does not bring the element back. Only true and false are valid values, so a value such as “yes” is an error.

Can aria-hidden be on focusable elements?

The attribute can be placed on an element that is focusable, but the focusable element must not be reachable by keyboard while it is hidden. A link or button inside an aria-hidden=“true” element that stays in the Tab order is flagged as an error. Remove it from the Tab order with tabindex="-1" or the inert attribute, or stop hiding it.

Does aria-hidden hide an element on the screen?

No. aria-hidden only changes what screen readers announce. The element stays visible unless CSS hides it, for example with display: none or visibility: hidden.

Does aria-hidden on the body hide the whole page?

Yes, and that is an error. aria-hidden=“true” on the body or html element hides the entire page from screen readers. The axe-core accessibility engine reports it as a violation (rule aria-hidden-body).

Why does the checker not warn about my icon?

Decorative icons, such as svg and i elements or empty elements, produce no warning when they are inside an aria-hidden=“true” element. The warning only applies to visible text, which screen reader users would miss.

Does the checker read my CSS or JavaScript?

No. It checks only the HTML you paste. It cannot see style sheets, scripts that change the DOM later, or the effect of inert from outside the snippet.