Issues by category

What the issue is

The use of the "aria-labelledby" attribute is a powerful way to provide accessible names for buttons, especially when text alone does not convey enough context, or when aiming to combine text from multiple sources. 

What the issue is

Buttons across a web page that lack consistent activation methods pose a significant barrier to users, especially those relying on assistive technologies or different input methods (e.g., keyboard vs. mouse). If some buttons only activate on a mouse click without a corresponding keyboard event, such as pressing the "Enter" or "Space" key, this can prevent keyboard users from interacting with those elements entirely.  

What the issue is

Toggle buttons that do not clearly communicate their state (e.g., "on" or "off") to the user can lead to confusion and difficulty in understanding the current state of the interface. This issue is often observed in buttons that change function or appearance when activated but do not provide adequate feedback to signify this change, especially to assistive technology users. An example of this issue is a "mute" button that changes function to "unmute" when activated but does not change its label or provides any other form of state indication.

What the issue is

Buttons that lack clear keyboard focus indicators make it difficult for users who rely on keyboard navigation to determine which element has focus. This issue typically arises in custom-styled web pages where the default focus styles provided by browsers have been overridden or removed. Without visible focus indicators, keyboard users may lose track of their current position on the page, leading to a frustrating and inefficient navigation experience.

What the issue is

Buttons that are inadequately labeled or utilize generic text such as "click here" or "submit" without providing context of the action being performed can significantly reduce accessibility. Users, especially those relying on screen readers, may not understand the purpose of the button or the action it initiates. This lack of clarity can lead to confusion and impede the ability to navigate and use a website effectively.

What the issue is

Buttons with text that is too small or lacks sufficient contrast against the button background can be difficult to read for many users. This readability issue can particularly impact users with vision impairments, including those with low vision or color vision deficiencies. Ensuring text within buttons is clearly legible is crucial for all users to identify and understand the function of each button.

What the issue is

Incorrect application of ARIA (Accessible Rich Internet Applications) roles to buttons can lead to significant accessibility challenges. For example, a <div> or <span> element being used as a button without an appropriate role="button" attribute fails to convey its function to assistive technology users. Similarly, misuse of ARIA attributes, such as using "aria-pressed" on buttons that do not toggle state, can provide misleading information.

What the issue is

Buttons with insufficient size and spacing can significantly impede usability for many users. Small buttons or buttons placed too closely together can be difficult to target, especially for users with motor impairments who may have difficulty accurately clicking or tapping the desired button. Touchscreen users and those using alternative pointing devices, such as a stylus, also face challenges when interacting with small or closely spaced buttons.

What the issue is

Buttons that do not provide visual feedback when interacted with (e.g., via mouse hover, focus, or activation) can cause confusion and uncertainty for users. Visual cues such as changes in color, elevation, enclosing box,  or animation help indicate that a button can be interacted with and has indeed been activated or is currently focused. Without these cues, users, especially those with visual impairments or cognitive disabilities, may struggle to understand whether their actions have been registered.

What the issue is

When the visible label text of a button does not match its accessible name (the name exposed to assistive technologies), it can lead to confusion and inconsistency for users relying on screen readers or other assistive technologies. An example of this issue is when a button labeled "Submit Form" on the screen has an accessible name of "Go" due to a mismatch in the `aria-label` attribute.

What the issue is

Using heading tags (h1, h2, h3, etc.) for styling purposes rather than to structure content hierarchically misleads users who rely on assistive technologies. For example, choosing an <h4> tag because it visually matches the desired text size, despite it being a primary section title that logically should be an <h1> or <h2>. This misuse of headings disrupts the document's structure, leading users to misinterpret the level of importance of various sections on the page.

What the issue is

Using headings (h1, h2, h3, etc.) improperly by skipping levels in the page structure can make it confusing for users who rely on assistive technologies to navigate web content. For example, moving directly from an h1 to an h3 heading without an intervening h2 disrupts the hierarchical structure of a page.

What the issue is

Web pages that dynamically update content without refreshing the entire page may fail to adjust the lang attribute to match the new content's language. This scenario can occur in single-page applications, AJAX content updates, or any dynamic content change that involves a language switch not reflected in the document's language settings.

What the issue is

Content that includes words or phrases that require specific phonetic pronunciation or pronunciation guidance without proper annotation can create barriers for users, including those using text-to-speech (TTS) technologies. This may include scientific terms, foreign language words, names, or any content where the pronunciation is not clear from the spelling.

What the issue is

When including subdocuments within a webpage through elements like <iframe>, the omission of a lang attribute in the subdocuments can result in incorrect language identification and processing by assistive technologies. This misidentification can disrupt the user's ability to comprehend the content, especially if the language in the subdocument is different from the parent document.

What the issue is

Automatic language detection inaccurately assesses the user's preferred language, leading to a webpage being displayed in a language the user cannot understand. This often occurs with websites trying to automatically set the language based on the user's location (via IP address) or browser settings, without allowing an easy way for the user to change the language back to their preferred choice.

What the issue is

Content in languages that are read right-to-left (RTL), such as Arabic and Hebrew, or those that may use vertical text directions, requires HTML elements to correctly manage text directionality. This includes using the dir attribute appropriately on elements or through CSS to ensure text is correctly aligned and read in its intended direction. Failure to do so can result in text that is difficult to read, comprehend, or interact with effectively.

What the issue is

Forms and interactive widgets that do not support input in the user's preferred or native language create barriers. This issue arises in scenarios such as search boxes that only accept input in a certain language, form validation that incorrectly flags inputs in other languages as errors, or interfaces that do not accommodate right-to-left language inputs adequately.

What the issue is

Content that uses language at a level of complexity not suitable for its intended audience can hinder understanding, particularly for users with cognitive disabilities, learning difficulties, or limited proficiency in the language of the content. It also impact situational accessibility where users are busy or have limited capacity to attend to displayed text.