Accessibility Checking for Large Sites

The user-scalable="no" parameter in the <meta name="viewport"> element must not be used since it prevents text scaling and zooming, which are necessary for individuals with impaired vision.

The option user-scalable="no" within the content attribute of the <meta name="viewport"> element prevents page zooming.

The maximum-scale setting restricts the user’s ability to zoom. This is troublesome for individuals with low vision who rely on screen magnifiers to view web page content.

Users with partial or low vision frequently choose to increase their browser’s fonts to make web content easier to read. Everything visible in the browser window at a given time is the viewport focus. If the user maximizes the browser on a high-resolution display, the viewport’s focus area is expansive and may encompass the entire online page.

If the browser window is small, only a small portion of the web page is visible in the viewport focus region. The viewport focus of the browser has no effect on the programmatic focus. Users can scroll the web page up and down, but the focus does not follow the viewport. Developers are required by the Web Content Accessibility Guidelines to build pages to enable resizing up to 200%; nevertheless, it is considered best practice to demand a 5x zoom.

What this Accessibility Rule Checks

Ensures that the user-scalable="no" parameter is absent from the <meta name="viewport"> element, and that the maximum-scale parameter is greater than or equal to 500%

The user-scalable="no" parameter in the <meta name="viewport"> element must not be used since it prevents text scaling and zooming, which are necessary for individuals with impaired vision.

The option user-scalable="no" within the content attribute of the <meta name="viewport"> element prevents page zooming.

The maximum-scale setting restricts the user’s ability to zoom. This is troublesome for individuals with low vision who rely on screen magnifiers to view web page content.

Users with partial or low vision frequently choose to increase their browser’s fonts to make web content easier to read. Everything visible in the browser window at a given time is the viewport focus. On a high-resolution display, maximizing the browser provides a big viewport focus area that may include the entire online page.

If the browser window is small, only a small portion of the web page will be seen in the viewport focus region. The viewport focus of the browser has no effect on the programmatic focus. Users can scroll the web page up and down, but the focus does not follow the viewport. Developers are required by the Web Content Accessibility Guidelines to create websites to accommodate resizing up to 200%.

Ensures that user-scalable="no" is not included in the <meta name="viewport"> element and that maximum-scale is not less than 2.

What this Accessibility Rule Checks

Ensures that user-scalable="no" is not included in the <meta name="viewport"> element and that maximum-scale is not less than 2.

To enable screen reader users to navigate the heading structure with keyboard shortcuts rather than wasting time listening to more of the website to understand its structure, make sure the page, or at least one of its frames, contains a h1 element that appears before the start of the main content.

Users of screen readers can utilize keyboard keys to move straight to the first h1, which should, in theory, let them access the web page’s main content. Screen reader users must listen to more of the website in order to understand its structure if there is no h1 or if it appears elsewhere other than at the start of the main material, wasting significant time.

Keep in mind that unlike a visual user, a blind user cannot just glance at a web page and comprehend its layout. Without reading the entire material, visual users can learn a lot about the website layout. Users who are blind do not have such option. Unless there is another convenient way to gain a “glimpse,” screen readers read sequentially, which requires listening to the entire web page. It turns out that one method to do that is to use headers. Keyboard shortcuts can be used by screen reader users to move around a document’s heading hierarchy.

What this Accessibility Rule Checks

This rule locates every element that matches the subsequent selector and confirms that there is at least one of them: h1:not([role]), [role="heading"][aria-level="1"]

Checks to make sure elements selected for removal from the accessibility tree are really deleted.

In some circumstances, an element having a semantic role of none or presentation does not resolve to none or presentation (respectively).

This prevents the element from being eliminated from the accessibility tree, as would be expected, and allows screen readers to interact with it.

You shouldn’t focus the element or give it any global ARIA attributes in order to keep the element out of the accessibility tree.

What this Accessibility Rule Checks

Checks every element with role=“none” or role=“presentation” to ensure they do not have a global ARIA attribute and are not focusable.

A label element with a programmatic association must be included for each select element.

To make forms accessible, they must have clear form labels. Even if a form element isn’t programmatically named, sighted users can usually tell what it’s for when they see checkboxes, radio buttons, input fields, etc. To identify form fields, screen reader users need clear form labels. All form elements should have labels to remove confusion and make the product more accessible.

Screen reader users are in the dark about the expected input data when form elements lack labels. Without a defined label connection (or redundant text acting as a label), screen readers cannot automatically determine information about input items.

What this Accessibility Rule Checks

ensures that each select element has a label that is associated with it programmatically.

Touch targets must have a minimum dimension of 24 by 24 CSS pixels. The greatest unobscured area of the touch target is used to calculate size. The target must be at least 24 CSS pixels distant from any other touch target if its size is insufficient.

To be easily engaged without mistakenly triggering an adjacent target, touch targets need to be large enough and spaced apart. Users have trouble activating touch targets that are either too small or too close together.

All users who might find it challenging to confidently target or operate small controls can benefit from having targets with suitable size, or in the absence of that, sufficient target spacing. The following users gain, but are not restricted to:

• People who use a mobile device where touching the screen is the main form of interaction.
• Those who use a mouse, stylus, or touch input but have mobility issues like hand tremors.
• Those who use a device in environments where they are exposed to shaking, like on public transportation.
• Those who use a mouse but have trouble with fine motor movements; those who use a device with just one hand.
• Those who have large fingers or are using the device with just one hand.

What this Accessibility Rule Checks

Verify the touch target’s unobscured size and distance from other touch targets.