AChecker+ Web Accessibility Checker

AChecker+ Web Accessibility Checker | ACHECKS
AChecker+
FAQ
Is my site accessible?
With
ACHECKS
, you can test your webpages for accessibility across two free accessibility checkers, namely
AChecker
and
Lighthouse
. AChecker is based on the markup of your website and tests against the
WCAG
2.0 guidelines
. Whereas Lighthouse is based on the rendering of your website on an actual browser and checks against the
WCAG
2.1 AA guidelines
You can also test your PDFs via the
Tingtun
checker either on this page by pasting the URL of your PDF, or through the
upload PDF file tool
If you are specifically looking for a color contrast checker to test your color palettes, you may want to check out the
ACHECKS
WCAG
2 Accessible Color Contrast Checker
While automated tests do help with identifying many accessibility issues, they are not in and of themselves sufficient. For example, there are many things that cannot be automatically tested and do need manual checking. If you need help with this,
contact our support team
to engage our experts.
How do I use the ACHECKS accessibility checker?
You can either use the free checkers listed here on your individual webpages or PDF documents by pasting the URL and selecting the desired guideline.
If you prefer a more automated solution with regular compliance reporting generated across your entire domain, you can check out the
ACHECKS pricing plans
`[accesskey]` values are unique
Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique.
`[aria-*]` attributes match their roles
Each ARIA `role` supports a specific subset of `aria-*` attributes. Mismatching these invalidates the `aria-*` attributes.
Values assigned to `role=""` are valid ARIA roles.
ARIA `role`s enable assistive technologies to know the role of each element on the web page. If the `role` values are misspelled, not existing ARIA `role` values, or abstract roles, then the purpose of the element will not be communicated to users of assistive technologies.
`button`, `link`, and `menuitem` elements have accessible names
When an element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
Elements with `role="dialog"` or `role="alertdialog"` have accessible names.
ARIA dialog elements without accessible names may prevent screen readers users from discerning the purpose of these elements.
`[aria-hidden="true"]` is not present on the document ``
Assistive technologies, like screen readers, work inconsistently when `aria-hidden="true"` is set on the document ``.
`[aria-hidden="true"]` elements do not contain focusable descendents
Focusable descendents within an `[aria-hidden="true"]` element prevent those interactive elements from being available to users of assistive technologies like screen readers.
ARIA input fields have accessible names
When an input field doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
ARIA `meter` elements have accessible names
When a meter element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
ARIA `progressbar` elements have accessible names
When a `progressbar` element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
`[role]`s have all required `[aria-*]` attributes
Some ARIA roles have required attributes that describe the state of the element to screen readers.
Elements with an ARIA `[role]` that require children to contain a specific `[role]` have all required children.
Some ARIA parent roles must contain specific child roles to perform their intended accessibility functions.
`[role]`s are contained by their required parent element
Some ARIA child roles must be contained by specific parent roles to properly perform their intended accessibility functions.
`[role]` values are valid
ARIA roles must have valid values in order to perform their intended accessibility functions.
Elements with the `role=text` attribute do not have focusable descendents.
Adding `role=text` around a text node split by markup enables VoiceOver to treat it as one phrase, but the element's focusable descendents will not be announced.
ARIA toggle fields have accessible names
When a toggle field doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
ARIA `tooltip` elements have accessible names
When a tooltip element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
ARIA `treeitem` elements have accessible names
When a `treeitem` element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers.
`[aria-*]` attributes have valid values
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid values.
`[aria-*]` attributes are valid and not misspelled
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid names.
Buttons have an accessible name
When a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers.
The page contains a heading, skip link, or landmark region
Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently.
Background and foreground colors have a sufficient contrast ratio
Low-contrast text is difficult or impossible for many users to read.
`

` and `: ` groups, `