Accessibility Check

Our Accessibility Checker Is Featured On

Accessibility Checker: Is Your Website Accessible?

With EXPERTE.com's Accessibility Checker, you can find out how accessible your website is. The tool crawls your site, making sure that each subpage can be correctly displayed by screen readers, allowing even blind and visually-impaired users to make full use of it.

The accessibility test assesses 41 features across eight categories. The most important categories are:

Navigation
Our test checks whether the site's navigation is consistent and accessible.
ARIA
ARIA is a semantic HTML extension that makes websites more accessible for those with disabilities. Our test checks whether ARIA has been correctly implemented.
Names and labels
Among other things, our test also checks whether form fields and buttons are marked with meaningful labels, and if images have alternative text.
Contrast
For a significant number of users, text with low contrast is difficult or impossible to read. Our test checks whether the contrast ratio between background and foreground colors is sufficient.
Tables and lists
Screen readers offer functions that make navigating tables and lists much easier. We check whether these have been implemented correctly.
Audio & Video
If a video contains subtitles, those with hearing impairments users can better understand its content. This test checks if there are correct markups.
Internationalization & Localization
When you specify a valid language on your site, screen readers can correctly display text. Our test checks whether a valid language has been specified.

FAQs

What does website accessibility mean?

⊖

An accessible website is one that is designed in such a way that people with disabilities and impairments of any kind can use it without restriction.

Why should my website be accessible?

⊖

An accessible website can be enjoyed by everyone, regardless of their impairments or disabilities. This enables you to reach a larger target group, increase your site's usability, and contribute to integrating those with impairments into the Internet.

How does the Accessibility Checker work?

⊖

After entering a URL, EXPERTE.com's Accessibility Checker crawls your website, examining up to 500 URLs on it for accessibility. The test is based on Lighthouse, an open-source tool, with the score (from 0-100) indicating your site's technical accessibility.

Please note, that an automated accessibility check is only able to detect a subset of issues and that manual testing is always encouraged.

Accessibility Checks in Detail

Below you can find a description for each of the elements which our Accessibility Checker examines.

Navigation


1.	[accesskey] values are unique Through the input of a combination of keys, users can quickly focus on one aspect of a page. For proper navigation, each access key must be unique.
2.	The page contains a heading, skip (navigation) link, or landmark area Including means to bypass repetitive content lets keyboard users navigate pages more efficiently.
3.	[id] attributes on active, focusable elements are unique All focusable elements must have a unique id to ensure that they're readable by assistive technologies.
4.	Heading elements appear in a sequentially-descending order Properly ordered headings that do not skip levels endow pages with a semantic structure, making it easier for assistive technologies to navigate and understand them.
5.	No element has a [tabindex] value greater than 0 A value greater than 0 implies an explicit navigation order. Although technically valid, this often frustrates users who rely on assistive technologies.

ARIA


1.	*[aria-] attributes match their roles** Each ARIA role supports a specific subset of aria-* attributes. Mismatching these invalidates the aria-* attributes.
2.	[aria-hidden="true"] is not present on the document <body> Assistive technologies, like screen readers, do not work properly when aria-hidden="true" is set on the document <body>.
3.	[aria-hidden="true"] elements do not contain focusable sub-elements The presence of focussable sub-elements within an [aria-hidden="true"] element prevent those using assistive technologies like screen readers from taking full advantage of such interactive elements.
4.	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 uninformative for users who rely on screen readers.
5.	*[role]s have all required [aria-] attributes** For some ARIA roles, attributes are required for describing the state of the element to screen readers.
6.	Those elements with an ARIA [role], and their sub-elements that must have a specific [role], have all required child elements. Some ARIA parent roles must contain specific child roles to perform their intended accessibility functions
7.	[role]s are contained by their required parent element Some ARIA child roles must be subordinated to specific parent roles to properly perform their intended accessibility functions.
8.	[role] values are valid ARIA roles must have valid values in order to perform their intended accessibility functions.
9.	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 uninformative for screen reader users.
10.	*[aria-] attributes have valid values** Assistive technologies, like screen readers, are unable to interpret ARIA attributes if they have invalid values.
11.	*[aria-] attributes are valid and not misspelled** Similarly, assistive technologies, like screen readers, are unable to interpret ARIA attributes if they have invalid names.
12.	ARIA IDs are unique The value of an ARIA ID must be unique to prevent other instances from being overlooked by assistive technologies.

Names and Labels


1.	Buttons have an accessible name When a button doesn't have an accessible name, screen readers announce it as "button", making it uninformative for screen reader users.
2.	Document has a <title> element The title gives users of screen readers an overview of the page and helps those who use search engines to determine if a page is relevant to their search.
3.	None of the form fields have multiple labels Form fields with multiple labels can be confusingly announced by assistive technologies like screen readers using either their first, last, or all labels.
4.	<frame>- or <iframe> elements have a title Screen reader users rely on frame titles to describe their content.
5.	Image elements have [alt] attributes Informative elements should have short, descriptive alternate text. Decorative elements can be ignored with an empty alt attribute.
6.	<input type="image"> elements have [alt] text When an image is being used as an '<input>' button, providing alternative text can help screen reader users understand the button's purpose.
7.	Form elements have associated labels Labels ensure that form controls are announced properly by assistive technologies, like screen readers.
8.	Links have an easily discernible name Link text (and alternate text for images, when used as links) that is discernible, unique, and focusable improves the navigation experience for screen reader users.
9.	<object> elements have [alt] text Screen readers cannot translate non-textual content. Adding alt text to <object> elements helps screen readers impart its meaning to users.

Contrast


1.	Background and foreground colors have a sufficient contrast ratio. This is important as text with low contrast is difficult or impossible for many users to read.

Tables and Lists


1.	<dl>'s only contain properly-ordered <dt> and <dd> groups, <script>, <template>, or <div> elements When definition lists are not properly marked up, screen readers may produce confusing or inaccurate output.
2.	Definition list items are wrapped in <dl> elements Definition list items (<dt> and <dd>) must be wrapped in a parent <dl> element to ensure that screen readers can properly announce them.
3.	Lists only contain <li> elements and script supporting elements (<script> and <template>) Screen readers announce lists in a specific manner. Ensuring proper list structure improves the accuracy of screen reader output.
4.	List items (<li>) are contained within <ul> or <ol> parent elements In order to be announced properly by a screen reader list items (<li>) must be contained within a parent <ul> or <ol>.
5.	Presentational <table> elements avoid using <th>, <caption> or the [summary] attribute. A table that is being used for layout purposes should not include data elements, such as <th> or <caption>, or the [summary] attribute, since this can create a confusing experience for screen reader users.
6.	Cells in a <table> element that use the [headers] attribute refer to table cells within the same table Screen readers include features that make navigating tables easier. Ensuring <td> cells using the [headers] attribute only refer to other cells in the same table may improve the experience for screen reader users.
7.	<th> elements and elements with [role="columnheader"/"rowheader"] have data cells they describe Screen readers include features that make navigating tables easier. Ensuring table headers always refer to some set of cells can improve the site experience for screen reader users.

Best Practices


1.	The document does not use <meta http-equiv="refresh"> Users do not expect a page to refresh automatically, and doing so will return focus back to the top of the page, resulting in a frustrating or confusing experience.
2.	[user-scalable="no"]` is not used in the <meta name="viewport"> element and the [maximum-scale] attribute is not less than 5 By disabling zooming, users who rely on screen magnification to properly see the contents of a web page are greatly disadvantaged.

Audio & Video


1.	<video> elements contain a <track> element with [kind="captions"] Videos with captions are easier for deaf or hearing impaired users to access.
2.	<video> elements contain a <track> element with [kind="description"] Audio descriptions provide relevant information for videos that dialogue cannot relay, such as facial expressions and scenes.

Internationalization and Localization


1.	<html> element has a [lang] attribute If a page doesn't specify a [lang] attribute, a screen reader assumes that it is in the default language that the user chose when setting up the screen reader. If the page isn't actually in the default language, the screen reader might not announce the page's text correctly.
2.	<html> element has a valid value for its [lang] attribute Specifying a valid BCP 47 language helps screen readers announce text properly.
3.	[lang] attributes have a valid value Specifying a valid BCP 47 language on elements ensures that text is pronounced correctly by a screen reader.

Top Website Builder 2024