Images, icons, and other visuals are reviewed for accurate text alternatives, and the
web accessibility checker verifies that each element can be interpreted correctly by assistive technologies.
WHAT WE CHECK
All SVG graphics and icon elements are reviewed to confirm they
include ARIA labels or text alternatives. Decorative icons use role="presentation" or
aria-hidden="true", while meaningful ones include
accessible names via aria-label,
aria-labelledby, or title.
WHY IT MATTERS
Screen readers rely on these labels to describe icons and visuals.
Without them, users may miss important interface details or functions. Tabnav ADA accessibility checker evaluates
these elements to ensure they meet accessibility standards.
WHAT WE CHECK
Every <img> element must
include an alt attribute. Functional
images need meaningful alt text, while decorative ones use an empty value (alt="").
WHY IT MATTERS
Alternative text allows assistive technologies to describe images
accurately. Missing or incorrect alt text prevents users from understanding visual content, an
issue our WCAG checker identifies automatically.
WHAT WE CHECK
When a background image conveys meaning, it should include an
accessible name through aria-label,
aria-labelledby, or title, and use role="img" where
appropriate.
WHY IT MATTERS
Screen readers ignore background images unless labeled correctly.
Proper tagging ensures meaningful visuals remain accessible for all users.
WHAT WE CHECK
<canvas> and <object>
elements that display graphics or
media must include labels like aria-label, aria-labelledby,
or title, and a relevant role such
as role="img" or role="graphics-symbol".
WHY IT MATTERS
Without proper labeling, assistive tools cannot describe the visuals
inside these elements, leaving users without context or information. These checks form a key
part of our accessibility checker workflow.
WHAT WE CHECK
Both the main image and each clickable region in an image map need
descriptive alt text that identifies their function or destination.
WHY IT MATTERS
Screen readers depend on these descriptions to explain interactive
regions. Without them, image maps become confusing or unusable.
WHAT WE CHECK
Pages are checked to confirm users can zoom up to 200% without losing
functionality. The viewport settings and CSS should not limit scaling.
WHY IT MATTERS
Zooming is crucial for users with low vision. Restricting it creates
barriers and fails to meet accessibility standards.
WHAT WE CHECK
Every form field must have a visible label or instruction.
Placeholders alone do not qualify because they disappear while typing.
WHY IT MATTERS
Visible labels help users understand what information to provide,
especially those with cognitive or memory challenges.
WHAT WE CHECK
Links that open in new windows or tabs should include a clear
indicator such as text, an icon, or ARIA attribute to inform users before activation.
WHY IT MATTERS
Unexpected new windows can confuse users, particularly those with
cognitive or visual impairments. Indicators keep navigation predictable and ensure compliance
with best practices verified through our web accessibility checker.
WHAT WE CHECK
Headings (<h1> through <h6> or elements with role="heading") must contain text content. If a heading contains
only graphical elements like images, SVGs, or icons, those elements must have accessible names via
alt attributes, aria-label,
or aria-labelledby.
WHY IT MATTERS
Screen readers announce headings to help users navigate page structure.
Empty headings or headings with unlabeled graphics provide no useful information and create confusion
about page organization. Our accessibility checker identifies these issues.
WHAT WE CHECK
List items (<li> elements or
elements with role="listitem") must have a direct parent that
is a list container (<ul>, <ol>, <dl>, or
elements with role="list", role="menu", or role="menubar").
WHY IT MATTERS
Screen readers announce list context and the number of items to users.
When list items are not direct children of proper list containers, assistive technology cannot
accurately convey the list structure, count, or navigation context.
WHAT WE CHECK
Pages should contain exactly one <main> landmark (for primary content), exactly one banner
landmark (from top-level <header> or role="banner"), and exactly one contentinfo landmark (from
top-level <footer> or role="contentinfo").
WHY IT MATTERS
Landmarks are navigation shortcuts that screen reader users rely on to
quickly jump between page regions. When a page has multiple banner or contentinfo landmarks, users
cannot determine which is the actual site header or footer. Missing or duplicate main landmarks
prevent users from efficiently skipping navigation and jumping directly to the primary content.
WHAT WE CHECK
When multiple landmarks of the same type exist on a page (e.g., multiple
<nav> elements), each must have a unique accessible
name using aria-label, aria-labelledby, or title
attributes.
WHY IT MATTERS
Screen reader users navigate pages by jumping between landmarks. When
multiple landmarks of the same type exist without unique labels, users cannot distinguish between
them. For example, "navigation" and "navigation" provide no context, while "Main Navigation" and
"Footer Navigation" help users navigate efficiently.
WHAT WE CHECK
Submit buttons (button[type="submit"] or input[type="submit"]) must be contained within a <form> element. A submit button's purpose is to submit its
form owner - without being inside a form, the button has no programmatic relationship to any form.
WHY IT MATTERS
Submit buttons that are not inside a form element are non-functional -
they cannot submit any data. This creates confusion for all users, especially those using
assistive technologies who may attempt to interact with a button that appears to be a submit
button but does nothing.
Keyboard usability is tested across all interactive elements, while the accessibility
checker confirms clear focus states, predictable movement, and full operability without a mouse.
WHAT WE CHECK
All links must have descriptive text or ARIA labels that clearly state
their destination or purpose.
WHY IT MATTERS
Users navigating with screen readers rely on clear link names to
understand where each link leads. Vague or missing labels can cause confusion and prevent
effective navigation.
WHAT WE CHECK
When users navigate via keyboard, interactive elements must show a
visible focus outline, border, or highlight.
WHY IT MATTERS
A visible focus indicator shows users exactly where they are on the
page. Without it, those relying on keyboard navigation can easily lose track, creating
frustration and accessibility barriers.
WHAT WE CHECK
Each interactive element like buttons, links, and controls must
include an accessible name through visible text, aria-label, aria-labelledby, or title
attributes.
WHY IT MATTERS
Screen readers use these labels to announce the purpose of
interactive components. Missing names make it impossible for users to understand what an element
does or how to interact with it.
WHAT WE CHECK
Pages should include skip links allowing keyboard users to bypass
repetitive content like headers or menus and jump straight to the main section.
WHY IT MATTERS
Skip links improve efficiency for users who rely on keyboards or
screen readers, letting them navigate content faster. Evaluated as part of our WCAG
checker
scan.
WHAT WE CHECK
Hidden or off-screen elements must use tabindex="-1" or
aria-hidden="true" to remove them from the keyboard tab
order.
WHY IT MATTERS
Elements not visible to sighted users should not receive focus. If
they do, it can disorient screen reader users and break logical navigation.
WHAT WE CHECK
Every form control must have a programmatically associated label or
ARIA attribute so assistive technologies can announce its purpose.
WHY IT MATTERS
Without clear associations between labels and controls, users cannot
understand what input is required. Our ADA compliance check ensures these
relationships are
coded properly.
WHAT WE CHECK
When a dialog or popup is open, keyboard focus must remain inside it
until it is closed, preventing background interaction.
WHY IT MATTERS
Trapping focus ensures users do not accidentally tab into hidden
areas. This is essential for accessible modals and overlays.
WHAT WE CHECK
All dialogs and popups must provide a clear, keyboard-accessible exit
method like pressing Escape or selecting a visible close button.
WHY IT MATTERS
Users who depend on keyboard navigation must be able to close modals
without using a mouse. Missing exit options can trap users, breaking accessibility. Verified
during our web accessibility checker review.
WHAT WE CHECK
Focus should move only when the user triggers an action. Interactive
elements must not shift focus automatically.
WHY IT MATTERS
Unexpected focus movement can disorient screen reader users and those
with cognitive disabilities. Our internal accessibility testing ensures a
smooth and predictable
navigation flow.
WHAT WE CHECK
When a form control has both a visible label and an accessible name (via
aria-label, aria-labelledby, etc.), the accessible name must include the
exact text of the visible label to ensure consistency for all users.
WHY IT MATTERS
Users with motor impairments who use voice control software (like "click
Submit" or "click Email") rely on the visible label text being present in the accessible name.
When the accessible name differs from or does not include the visible label, voice commands may
fail, preventing these users from interacting with the form.
WHAT WE CHECK
Pages must contain exactly one <h1> element (or role="heading" with aria-level="1") that has an accessible name. The heading must be
visible in the accessibility tree (not removed via aria-hidden="true" or CSS like display:none).
WHY IT MATTERS
Screen reader users rely on the main heading to understand the page
purpose and navigate content. A page without any properly labeled main heading leaves users unable
to identify what the page is about, while multiple main headings create confusion about page
hierarchy.
Page hierarchy, headings, and landmarks are evaluated for clarity, and the WCAG checker
ensures the overall structure aligns with recognized accessibility patterns for assistive technologies.
WHAT WE CHECK
Elements that look like headings but are not coded with proper heading
tags must include role="heading" and a defined aria-level
(for example, aria-level="2").
WHY IT MATTERS
Assistive technologies depend on heading tags to navigate pages
efficiently. Missing or incorrect heading roles make it harder for users to understand page
hierarchy and content flow.
WHAT WE CHECK
Each form control must be programmatically linked to a label using
<label>, aria-label, or aria-labelledby attributes.
WHY IT MATTERS
When labels are not correctly connected, screen readers cannot
announce their purpose. Our ADA compliance check ensures users can complete
forms confidently
and independently.
WHAT WE CHECK
Every web page must include a descriptive <title> that clearly
reflects its purpose and context.
WHY IT MATTERS
Screen readers announce page titles first. Without clear or unique
titles, users may get lost or confused about which page they are on.
WHAT WE CHECK
Links must include accessible names that clearly describe their
destination or action through visible text, aria-label, or
title.
WHY IT MATTERS
Proper language markup ensures accurate pronunciation and translation
by assistive technologies. This is confirmed in our ADA checker review.
WHAT WE CHECK
Search fields should include role="search" on their parent element to
define an ARIA landmark region.
WHY IT MATTERS
Screen reader users can jump directly to the search section using
keyboard shortcuts. Verified through our web accessibility checker testing.
WHAT WE CHECK
The <html> element must
include a lang attribute to define the primary
language of the page.
WHY IT MATTERS
Invalid nesting can confuse assistive technologies and break expected
keyboard behavior, making content difficult to use.
WHAT WE CHECK
Text written in a language different from the page's default must use
its own lang attribute.
WHY IT MATTERS
Proper language markup ensures accurate pronunciation and translation
by assistive technologies. This is confirmed in our ADA checker review.
WHAT WE CHECK
Elements that act like buttons, links, or menus must include correct
ARIA roles if not using semantic HTML tags.
WHY IT MATTERS
Without defined roles, screen readers may not detect interactions
properly, causing usability issues for people relying on assistive devices.
WHAT WE CHECK
Interactive elements (like links or buttons) must not be nested
inside one another unless part of a valid HTML pattern.
WHY IT MATTERS
Invalid nesting can confuse assistive technologies and break expected
keyboard behavior, making content difficult to use.
WHAT WE CHECK
Interactive elements must contain visible text or accessible names
defined with aria-label, aria-labelledby, or title.
WHY IT MATTERS
Without names or text, users cannot identify the function of buttons
or links.
WHAT WE CHECK
Visually hidden interactive elements must include aria-hidden="true" if they are not intended for user
interaction.
WHY IT MATTERS
Screen reader users may encounter non-functional or decorative
elements, leading to confusion. Hiding them properly ensures clarity and focus.
WHAT WE CHECK
Form control labels (<label>)
should not contain additional interactive elements such as links or buttons, other than the
implicitly associated form control. Additional interactive elements make it difficult for users to
activate the form input associated with the label.
WHY IT MATTERS
When a label contains multiple interactive elements, it creates confusion
about what will be activated when users click or tap. Screen reader users may not understand which
element they are interacting with, and keyboard users may have difficulty navigating between the
label's form control and other interactive elements.
WHAT WE CHECK
When a menu or list item contains a submenu, the clickable element that
opens it (such as a button or link) must have the aria-haspopup attribute to inform assistive technology users that
activating it will reveal additional options.
WHY IT MATTERS
Screen reader users need to know when an item has a submenu before
activating it. Without aria-haspopup, users may be surprised
by unexpected navigation changes or miss nested content entirely. This is especially critical in
navigation menus where submenus open on hover or click.
WHAT WE CHECK
Elements with role="listbox" must
contain one or more descendant elements with role="option".
This establishes the proper parent-child relationship required for assistive technologies to
understand and navigate the listbox structure.
WHY IT MATTERS
Screen reader users rely on the proper ARIA structure to understand
available options in a listbox. Without option descendants, assistive technologies cannot
communicate the selectable items to users, making the listbox unusable for people with
disabilities.
WHAT WE CHECK
Elements with role="option" can only
contain text and must not include interactive elements such as links, buttons, or other focusable
elements. All descendants of option elements are automatically treated as presentational.
WHY IT MATTERS
When an option contains interactive elements like links, those elements
lose their semantics and functionality for screen reader users. The accessibility API cannot
represent semantic elements within an option, making nested interactive elements inaccessible.
WHAT WE CHECK
Form elements (<form> or [role="form"]) create form landmarks that must have
programmatically determinable accessible names through aria-label, aria-labelledby, or title
attributes.
WHY IT MATTERS
Form landmarks without accessible names cannot be properly identified by
assistive technologies. Screen reader users navigating by landmarks will hear "form" without any
context about the form's purpose, making it difficult to distinguish between multiple forms or
understand what each form is for.
WHAT WE CHECK
The <summary> element itself
is interactive (it functions as a disclosure button for <details> elements). Placing interactive elements like
links, buttons, or form controls inside a <summary>
creates nested interactive contexts that break keyboard navigation.
WHY IT MATTERS
When a summary element contains interactive descendants, those nested
elements will not be consistently accessible to people navigating by keyboard or using assistive
technology. The summary element itself captures click and keyboard events to toggle the details
element, preventing reliable access to nested interactive elements.
WHAT WE CHECK
When a list item or menu item contains a submenu, the interactive element
that opens it must have aria-expanded="true" when the
submenu is visible and aria-expanded="false" when hidden.
This value must update dynamically to reflect the current state.
WHY IT MATTERS
Screen reader users cannot visually see whether a submenu is expanded or
collapsed. Without accurate aria-expanded state, users do not
know if submenus are open, may activate already-expanded items thinking they are collapsed, or
navigate away thinking there is no more content when submenus are actually open.
