Accessibility Check

Accessibility Checker - Is my website accessible?

With the EXPERTE.com Accessibility Test you can determine the accessibility your website. The tool crawls your website and checks for each subpage if it can be correctly displayed by screen readers. This means that even blind and visually impaired users can fully use your website.

The accessibility test checks 41 features in 8 categories. The most important categories are:

Navigation
Our test checks whether the navigation on the site is barrier-free and consistent.

ARIA
ARIA is a semantic extension for HTML to make websites more accessible for people with disabilities. Our test checks the correct implementation.

Names and labels
Among other things, our test checks whether form fields and buttons are marked with meaningful labels and whether images have an alternative text.

Contrast
Text with low contrast is difficult or impossible to read for many users. The test checks whether the contrast ratio of background and foreground colors is sufficient.

Tables and lists
Screen readers offer functions that simplify navigation in tables and lists. We check whether both have been implemented correctly.

Audio & Video
If a video contains subtitles, deaf and hearing impaired users can better understand the information in the video. The test checks if there are correct markups.

Internationalization & Localization
By specifying a valid language, the text of a web page can be displayed correctly by a screen reader. The test checks whether a valid language is specified.

Frequently asked questions

What does website accessibility mean?
An accessible website is designed in such a way that people with visual impairments, blind people and deaf people can use the offer without restriction.

Why should my website be accessible?
With a accessible website you make it possible for everyone to use your offer without restrictions. You reach a larger target group, increase the usability of your site and contribute to the digital participation of people with disabilities.

How does the Accessibility Checker work?
After entering a URL, the EXPERTE.com Accessibility Checker crawls your website and checks every subpage for accessibility. The test is based on the open-source tool Lighthouse. Up to 500 URLs can be checked. The score indicates the technical accessibility on a scale of 0-100.

Accessibility checks in detail

Below you will find the description of all the checks performed by our Accessibility Checker.

Navigation

1.

[accesskey] values are unique
Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique.

2.

The page contains a heading, skip link, or landmark region
Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently.

3.

[id] attributes on active, focusable elements are unique
All focusable elements must have a unique id to ensure that they're visible to assistive technologies.

4.

Heading elements appear in a sequentially-descending order
Properly ordered headings that do not skip levels convey the semantic structure of the page, making it easier to navigate and understand when using assistive technologies.

5.

No element has a [tabindex] value greater than 0
A value greater than 0 implies an explicit navigation ordering. Although technically valid, this often creates frustrating experiences for 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, work inconsistently when aria-hidden="true" is set on the document <body>.

3.

[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.

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 unusable for users who rely on screen readers.

5.

[role]s have all required [aria-*] attributes
Some ARIA roles have required attributes that describe the state of the element to screen readers

6.

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

7.

[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.

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 name
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.

10.

[aria-*] attributes have valid values
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid values.

11.

[aria-*] attributes are valid and not misspelled
Assistive technologies, like screen readers, can't interpret ARIA attributes with 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 unusable for users who rely on screen readers.

2.

Document has a <title> element
The title gives screen reader users an overview of the page, and search engine users rely on it heavily to determine if a page is relevant to their search.

3.

No form fields have multiple labels
Form fields with multiple labels can be confusingly announced by assistive technologies like screen readers which use either the first, the last, or all of the labels.

4.

<frame>- or <iframe> elements have a title
Screen reader users rely on frame titles to describe the contents of frames.

5.

Image elements have [alt] attributes
Informative elements should aim for 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 purpose of the button.

7.

Form elements have associated labels
Labels ensure that form controls are announced properly by assistive technologies, like screen readers.

8.

Links have a 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-text content. Adding alt text to <object> elements helps screen readers convey meaning to users.

Contrast

1.

Background and foreground colors have a sufficient contrast ratio
Low-contrast text is difficult or impossible for many users to read.

Tables and lists

1.

<dl>'s contain only 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 contain only <li> elements and script supporting elements (<script> and <template>)
Screen readers have a specific way of announcing lists. Ensuring proper list structure aids screen reader output.

4.

List items (<li>) are contained within <ul> or <ol> parent elements
Screen readers require list items (<li>) to be contained within a parent <ul> or <ol> to be announced properly.

5.

Presentational <table> elements avoid using <th>, <caption> or the [summary] attribute.
A table being used for layout purposes should not include data elements, such as the th or caption elements or the summary attribute, because 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 have features to 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 have features to make navigating tables easier. Ensuring table headers always refer to some set of cells may improve the 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 move focus back to the top of the page. This may create 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
Disabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page.

Audio & Video

1.

<video> elements contain a <track> element with [kind="captions"]
When a video provides a caption it is easier for deaf and hearing impaired users to access its information.

2.

<video> elements contain a <track> element with [kind="description"]
Audio descriptions provide relevant information for videos that dialogue cannot, 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 the page 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, then 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 helps ensure that text is pronounced correctly by a screen reader.

Other languages:
Deutsch