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. Our ADA
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.
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.
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.
