Accessibility Checking for Large Sites
Rocket Validator integrates axe-core version 4.6, into an automated web site scanner.
Accessibility rules tagged as blind.
The h1
through h6
element tags must be in a sequentially-descending order for headings to be in a correct logical order.
The fundamental goal of headers is to communicate the page’s organizational structure. The same goal is served by employing various font sizes for sighted users.
For screen reader users, however, text size is useless because a screen reader can only recognize a header if it is correctly marked up. When header components are used correctly, both sighted and screen reader users will find it much simpler to traverse the page.
Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.
Headings serve to explain the organization of the webpage, not only to draw attention to key text. They ought to be succinct, distinct, and accompanied by h1
through h6
components used in hierarchical order. Headings are useful tools for screen reader users because of all of these characteristics. Screen reader users can move among headings in a manner akin to how sighted readers can quickly scan a page and get a sense of its content. Screen readers can save time and stress by using headings that are clearly written and arranged.
Since search engines employ headings when filtering, arranging, and showing results, headings offer other advantages outside just making the page more easily accessible. Making your website more searchable is another benefit of making it more accessible.
What this Accessibility Rule Checks
Ensures the semantic accuracy of the headings’ order.
Notifies users of content that is hidden and unable to be checked for accessibility issues.
It is impossible to automatically check hidden content for accessibility rules breaches.
Screen reader users and sighted people must both be able to view visually hidden content. When content needs to be hidden from seeing users for a compelling reason, it is typically also necessary to hide it from blind users for the same reason. Making the content accessible to blind users makes sense when it is already available to sighted users.
When the CSS values display: none
or visibility: hidden
are used, content will be hidden from screen reader users (and all sighted users as well). The items become accessible to screen reader users when CSS properties are changed to display: block
, display: inline
, or other display values.
What this Accessibility Rule Checks
Checks for the presence of the hidden item content CSS style property values of display: none
and visibility: hidden
, and notifies users of their presence.
For multilingual screen reader users who would prefer a language other than the default, the HTML document element must have a valid lang
property or match to a valid lang
code.
The default language is chosen by users when setting up a screen reader. The screen reader uses the user’s default language preference when a webpage’s language is not specified. When people visit websites in more than one language and speak various languages, language settings become a problem. To ensure that website text is pronounced accurately, a language must be specified and validated.
Based on the pronunciation and traits of each language, screen readers employ distinct sound libraries for each one. If the documents state which language(s) to read when, screen readers can effortlessly switch between these language libraries. The screen reader will read the page in the user’s default language if the language is not set, which will result in an odd accent. When screen readers are utilizing the incorrect language library, nothing can be understood.
What this Accessibility Rule Checks
Ensures that the lang
attribute is present in every HTML document.
For multilingual screen reader users who may prefer a language different than the default, the HTML content must contain a valid lang
attribute or correlate to a valid lang
code.
Users choose a default language when configuring a screen reader. If the language of a webpage is not provided, the screen reader uses the user’s default language. Language settings are a problem for users who speak different languages and visit websites in multiple languages. It is critical to declare a language and guarantee that it is valid in order for website text to be properly pronounced.
Screen readers employ various sound libraries for each language based on its pronunciation and characteristics. Screen readers can readily switch between these language libraries, but only if the documents specify which language(s) they should read. If no language is supplied, the screen reader reads the content in the user’s default language, which results in a perplexing accent! When screen readers use the incorrect language library, it is difficult to understand anything.
What this Accessibility Rule Checks
Ensures that every HTML document contains a lang
or xml:lang
property with a valid value.
When was the last time you validated your whole site?
Keep your sites healthy checking for A11Y/HTML issues on an automated schedule.
For multilingual screen reader users who may prefer a language different than the default, the HTML content must contain a valid lang
attribute or correlate to a valid lang
code. If included on the html
element, the xml:lang
property value must exactly duplicate the value of the lang
.
Users choose a default language when configuring a screen reader. If the language of a webpage is not provided, the screen reader uses the user’s default language. Users who speak and access websites in various languages have difficulties. For screen readers to function properly, a default language must be specified and ensured to be valid.
Screen readers employ various sound libraries for each language based on its pronunciation and characteristics. Screen readers can simply switch between language libraries if documents specify which language(s) should be read. Screen readers view texts in the user’s default language if the language is not specified, resulting in distorted language. When screen readers use the incorrect language library, it can be difficult to understand anything.
What this Accessibility Rule Checks
Ensures that every HTML document includes a valid lang
attribute, and that the xml:lang
value, if present, replicates the lang value.
Check that all links with the same accessible name fulfill the same function.
This guideline is significant since the goal is to assist viewers in understanding the purpose of each link in the material so they may determine whether or not to follow it. Links with the same destination should have the same descriptions, but links with different purposes and destinations should have different descriptions (see also Success Criterion 3.2.4), which calls for consistency in identifying components with the same functionality). Links can be understood when they are out of context, such as when the user agent presents a list of all the links on a page, because the purpose of a link can be inferred from its link text.
What this Accessibility Rule Checks
This rule’s algorithm yields:
-
Undefined for a native link with the
href
attribute but no visible name. - Undefined when there is no accessible name for an ARIA link.
- Undefined when the accessible name of an ARIA link is merely a collection of unicode (emoji, punctuation, nonBmp) characters.
-
True for native links with an accessible name and a
href
attribute value. -
True for ARIA links with accessible names (for example, a
area
withmap
used in aimage
element). -
True for native links having
href
attribute values and a name that can be found (that also has emoji, nonBmp and punctuation characters).
12,500 Accessibility and HTML checks per week. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.
To express their purpose and meaning to screen reader users, all images must include alternate text.
Even if the image just contains text, screen readers have no way of translating it into words that are read to the user. As a result, photos must have concise, descriptive alt
text so that screen reader users grasp the image’s contents and purpose.
If you can’t see, all visual information, such as photographs, is meaningless unless a digital text equivalent is provided so that screen readers may translate that text into either sound or braille. People with limited eyesight or colorblindness experience the same phenomenon to varied degrees.
Screen readers cannot translate an image into speech or braille to make it available by sound or touch if you do not provide a suitable alternative that works for their available sensory modalities, such as making an image accessible by providing a digital text description.
What this Accessibility Rule Checks
Ensures that all <image>
elements have alternative text and either role="presentation"
or role="none"
(ARIA 1.1).
When button and link text in an alt
property value repeats, screen reader users hear the same information twice, rendering the alt text worthless and confusing.
It is redundant and potentially misleading to have alternate text for a link or image repeated in text adjacent to the link or image because a screen reader would read it twice.
Because image buttons employ alt
attributes for labels, the labels should not repeat the text next to the button. Screen readers announce the text to the user twice when there is duplicate alternative text for an image or link in the text adjacent to that image or link.
What this Accessibility Rule Checks
Make certain that the button and link text are not repeated as picture alternatives.
Ensures that input buttons have legible text.
Without an accessible name, screen reader users cannot determine the purpose of a input type="button"
.
Without a discernible and accessible name, screen reader users cannot grasp the purpose of an image. A title for a photograph may just convey advisory information about the image. When used as a control, unnamed actionable visual images such as buttons have no clear definition of the destination, purpose, function, or action for the non-text material.
What this Accessibility Rule Checks
The text on input buttons must be readable.
Makes certain that <input type="image">
elements have alternate text.
Screen reader users will not understand the function of a <input type="image">
button unless equivalent wording is provided. Even if the image merely contains text, alternate text is required because a screen reader cannot interpret images of words into output.
Simply typing text adjacent to the form element will not result in a true label. Screen readers, for example, require labels in code that can be determined automatically.
Some screen readers are configured to estimate the label based on the surrounding text, however this method is not foolproof and might cause confusion if the screen reader guesses incorrectly.
What this Accessibility Rule Checks
Ensures that each <input type="image">
has a name that can be found.
50,000 Accessibility and HTML checks per month. Fully automated.
Let our automated scanner check your large sites using Axe Core and W3C Validator.