aria - freeCodeCamp.org

How to Build Responsive and Accessible UI Designs with React and Semantic HTML

Gopinath Karunanithi — Tue, 07 Apr 2026 17:06:31 +0000

Building modern React applications requires more than just functionality. It also demands responsive layouts and accessible user experiences.

By combining semantic HTML, responsive design techniques, and accessibility best practices (like ARIA roles and keyboard navigation), developers can create interfaces that work across devices and for all users, including those with disabilities.

This article shows how to design scalable, inclusive React UIs using real-world patterns and code examples.

Prerequisites
Overview
Why Accessibility and Responsiveness Matter
Core Principles of Accessible and Responsive Design
Using Semantic HTML in React
Structuring a Page with Semantic Elements
Building Responsive Layouts
Accessibility with ARIA
Keyboard Navigation
Focus Management
Forms and Accessibility
Responsive Typography and Images
Building a Fully Accessible Responsive Component (End-to-End Example)
Testing Accessibility
Best Practices
When NOT to Overuse Accessibility Features
Future Enhancements
Conclusion

Prerequisites

Before following along, you should be familiar with:

React fundamentals (components, hooks, JSX)
Basic HTML and CSS
JavaScript ES6 features
Basic understanding of accessibility concepts (helpful but not required)

Overview

Modern web applications must serve a diverse audience across a wide range of devices, screen sizes, and accessibility needs. Users today expect seamless experiences whether they are browsing on a desktop, tablet, or mobile device – and they also expect interfaces that are usable regardless of physical or cognitive limitations.

Two essential principles help achieve this:

Responsive design, which ensures layouts adapt to different screen sizes
Accessibility, which ensures applications are usable by people with disabilities

In React applications, these principles are often implemented incorrectly or treated as afterthoughts. Developers may rely heavily on div-based layouts, ignore semantic HTML, or overlook accessibility features such as keyboard navigation and screen reader support.

This article will show you how to build responsive and accessible UI designs in React using semantic HTML. You'll learn how to:

Structure components using semantic HTML elements
Build responsive layouts using modern CSS techniques
Improve accessibility with ARIA attributes and proper roles
Ensure keyboard navigation and screen reader compatibility
Apply best practices for scalable and inclusive UI design

By the end of this guide, you'll be able to create React interfaces that are not only visually responsive but also accessible to all users.

Why Accessibility and Responsiveness Matter

Responsive and accessible design isn't just about compliance. It directly impacts usability, performance, and reach.

Accessibility benefits:

Supports users with visual, motor, or cognitive impairments
Improves SEO and content discoverability
Enhances usability for all users

Responsiveness benefits:

Ensures consistent UX across devices
Reduces bounce rates on mobile
Improves performance and scalability

Ignoring these principles can result in broken layouts on smaller screens, poor screen reader compatibility, and limited reach and usability.

Core Principles of Accessible and Responsive Design

Before diving into the code, it’s important to understand the foundational principles.

1. Semantic HTML First

Semantic HTML refers to using HTML elements that clearly describe their meaning and role in the interface, rather than relying on generic containers like

or .These elements provide built-in accessibility, improve SEO, and make code more readable.

For example:

Non-semantic:

Submit

Semantic:

Another example:

Non-semantic:

My App

Semantic:

My App

Using semantic elements such as

, and

Then, React can enhance it with validation, dynamic feedback, or animations.

By prioritizing functionality first and enhancements later, you ensure your application remains usable in a wide range of real-world scenarios.

4. Keyboard Accessibility

Keyboard accessibility ensures that users can navigate and interact with your application using only a keyboard. This is critical for users with motor disabilities and also improves usability for power users.

Key aspects of keyboard accessibility include:

Ensuring all interactive elements (buttons, links, inputs) are focusable
Maintaining a logical tab order across the page
Providing visible focus indicators (for example, outline styles)
Supporting keyboard events such as Enter and Space

Bad Example (Not Accessible)

Submit

This element:

Cannot be focused with a keyboard
Does not respond to Enter/Space
Is invisible to screen readers

Good Example

This automatically supports:

Keyboard interaction
Focus management
Screen reader announcements

Custom Component Example (if needed)

 {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      handleClick();
    }
  }}
>
  Submit

But only use this when native elements aren't sufficient.

These principles form the foundation of accessible and responsive design:

Use semantic HTML to communicate intent
Design for mobile first, then scale up
Enhance progressively for better compatibility
Ensure full keyboard accessibility

Applying these early prevents major usability and accessibility issues later in development.

Using Semantic HTML in React

As we briefly discussed above, semantic HTML plays a critical role in both accessibility (a11y) and code readability. Semantic elements clearly describe their purpose to both developers and browsers, which allows assistive technologies like screen readers to interpret and navigate the UI correctly.

For example, when you use a

Why this is better:

The
It is automatically focusable and keyboard accessible
It supports Enter and Space key activation by default
Screen readers correctly announce it as a button

This reduces complexity while improving accessibility and usability.

Why all this matters:

There are many reasons to use semantic HTML.

First, semantic elements like


  );
}

How this works:

role="dialog" identifies the element as a modal dialog
aria-modal="true" indicates that background content is inactive
aria-labelledby connects the dialog to its visible title for screen readers
tabIndex={-1} allows the dialog container to receive focus programmatically
Focus is moved to the dialog when it opens
Pressing Escape closes the modal, which is a standard accessibility expectation

This ensures that users can understand, navigate, and exit the modal using both keyboard and assistive technologies.

Key ARIA Attributes

1. role

Defines the type of element and its purpose. For example, role="dialog" tells assistive technologies that the element behaves like a modal dialog.

2. aria-label

Provides an accessible name for an element when visible text is not sufficient. Screen readers use this label to describe the element to users.

3. aria-hidden

Indicates whether an element should be ignored by assistive technologies. For example, aria-hidden="true" hides decorative elements from screen readers.

4. aria-live

Used for dynamic content updates. It tells screen readers to announce changes automatically without requiring user interaction (for example, form validation messages or notifications).

Example: Accessible Dropdown (Custom Component)

function Dropdown({ isOpen, toggle }) {
  return (
    
      

      {isOpen && (
        
          
            
          
          
            
          
        
      )}
    
  );
}

How this works:

aria-expanded indicates whether the dropdown is open or closed
aria-controls links the button to the dropdown content via its id
The
The
- elements provide a natural list structure
- Using elements ensures proper navigation behavior and accessibility
Why this approach is correct:
- It follows standard web patterns instead of application-style menus
- It avoids misusing ARIA roles like role="menu", which require complex keyboard handling
- Screen readers can correctly interpret the structure without additional roles
- It keeps the implementation simple, accessible, and maintainable
If you need advanced menu behavior (like arrow key navigation), then ARIA menu roles may be appropriate – but only when fully implemented according to the ARIA Authoring Practices.

Note: Most dropdowns in web applications are not true "menus" in the ARIA sense. Avoid using role="menu" unless you are implementing full keyboard navigation (arrow keys, focus management, and so on).

Keyboard Navigation

Keyboard navigation ensures that users can fully interact with your application using only a keyboard, without relying on a mouse. This is essential for users with motor disabilities, but it also benefits power users and developers who prefer keyboard-based workflows.

In a well-designed interface, users should be able to:
- Navigate through interactive elements using the Tab key
- Activate buttons and links using Enter or Space
- Clearly see which element is currently focused
In the example below, we’ll look at common mistakes in keyboard handling and why relying on native HTML elements is usually the better approach.

Example:
Avoid adding custom keyboard handlers to native elements like
This automatically supports:
- Enter and Space key activation
- Focus management
- Screen reader announcements
Adding manual keyboard event handlers here is unnecessary and can introduce bugs or inconsistent behavior.

What this example shows:
Avoid manually handling keyboard events for native interactive elements like
Why this works:
- Supports both Enter and Space key activation by default
- Is focusable and participates in natural tab order
- Provides built-in accessibility roles and screen reader announcements
- Reduces the need for additional logic or ARIA attributes
Adding custom keyboard handlers (like onKeyDown) to native elements is unnecessary and can introduce bugs or inconsistent behavior. Always prefer native HTML elements for interactivity whenever possible.

Avoiding Common Keyboard Traps

One of the most common keyboard accessibility issues is “trapping users inside interactive components”, such as modals or custom dropdowns. This happens when focus is moved into a component but can't escape using Tab, Shift+Tab, or other keyboard controls. Users relying on keyboards may become stuck, unable to navigate to other parts of the page.

In the example below, you'll see a simple modal that tries to set focus, but doesn’t manage Tab behavior properly.
```
function Modal({ isOpen }) {
  const ref = React.useRef();

  React.useEffect(() => {
    if (isOpen) ref.current?.focus();
  }, [isOpen]);

  return (
    
      
    
  );
}
```
What this code shows:
- When the modal opens, focus is moved to the Close button using ref.current.focus()
- The modal uses role="dialog" to communicate its purpose
There are some issues with this code that you should be aware of. First, tabbing inside the modal may allow focus to move outside the modal if additional focusable elements exist.

Users may also become trapped if no mechanism returns focus to the triggering element when the modal closes.

There's also no handling of Shift+Tab or cycling focus is present.

This demonstrates a partial focus management, but it’s not fully accessible yet.

To improve focus management, you can trap focus within the modal by ensuring that Tab and Shift+Tab cycle only through elements inside the modal.

You can also return focus to the trigger: when the modal closes, return focus to the element that opened it.

Example improvement (conceptual):
```
function Modal({ isOpen, onClose, triggerRef }) {
  const modalRef = React.useRef();

  React.useEffect(() => {
    if (isOpen) {
      modalref.current?.focus();
      // Add focus trap logic here
    } else {
      triggerref.current?.focus();
    }
  }, [isOpen]);

  return (
    
      
    
  );
}
```
Remember that this modal is not fully accessible without focus trapping. In production, use a library like focus-trap-react, react-aria, or Radix UI.

Key points:
- tabIndex={-1} allows the div to receive programmatic focus
- Focus trap ensures users cannot tab out unintentionally
- Returning focus preserves context, so users can continue where they left off
Best practices:
- Always move focus into modals
- Return focus to the trigger element when closed
- Ensure Tab cycles correctly
As a general rule, always prefer native HTML elements for interactivity. Only implement custom keyboard handling when building advanced components that cannot be achieved with standard elements.

Focus Management

Focus management is the practice of controlling where keyboard focus goes when users interact with components such as modals, forms, or interactive widgets. Proper focus management ensures that:
- Users relying on keyboards or assistive technologies can navigate seamlessly
- Focus does not get lost or trapped in unexpected places
- Users maintain context when content updates dynamically
The example below shows a common approach that only partially handles focus:

Bad Example:
```
// Bad Example: Automatically focusing input without context
const ref = React.useRef();
React.useEffect(() => {
  ref.current?.focus();
}, []);
```
In the above code, the input receives focus as soon as the component mounts, but there’s no handling for returning focus when the user navigates away.

If this input is inside a modal or dynamic content, users may get lost or trapped. There aren't any focus indicators or context for assistive technologies.

This is a minimal solution that can cause confusion in real applications.

Improved Example:
```
// Improved Example: Managing focus in a modal context
function Modal({ isOpen, onClose, triggerRef }) {  
const dialogRef = React.useRef();

  React.useEffect(() => {
    if (isOpen) {
      dialogRef.current?.focus();
    } else if (triggerRef?.current) {
      triggerref.current?.focus();
    }
  }, [isOpen]);

  React.useEffect(() => {
    function handleKeyDown(e) {
      if (e.key === 'Escape') {
        onClose();
      }
    }

    if (isOpen) {
      document.addEventListener('keydown', handleKeyDown);
    }

    return () => {
      document.removeEventListener('keydown', handleKeyDown);
    };
  }, [isOpen, onClose]);

  if (!isOpen) return null;

  return (
    
      Modal Title
      
      
    
  );
}
```
Explanation:
- tabIndex={-1} enables the dialog container to receive focus
- Focus is moved to the modal when it opens, ensuring keyboard users start in the correct context
- Focus is returned to the trigger element when the modal closes, preserving user flow
- aria-labelledby provides an accessible name for the dialog
- Escape key handling allows users to close the modal without a mouse
Note: For full accessibility, you should also implement focus trapping so users cannot tab outside the modal while it is open.

Tip: In production applications, use libraries like react-aria, focus-trap-react, or Radix UI to handle focus trapping and accessibility edge cases reliably.

Also, keep in mind here that the document-level keydown listener is global, which affects the entire page and can conflict with other components.
```
document.addEventListener('keydown', handleKeyDown);
```
A safer alternative is to scope it to the modal:
```
 {
    if (e.key === 'Escape') onClose();
  }}
>
```
For simple cases, attach onKeyDown to the dialog instead of the document.

Best Practice:

For complex components, use libraries like focus-trap-react or react-aria to manage focus reliably, especially for modals, dropdowns, and popovers.

Forms and Accessibility

Forms are critical points of interaction in web applications, and proper accessibility ensures that all users – including those using screen readers or other assistive technologies – can understand and interact with them effectively.

Proper labeling means that every input field, checkbox, radio button, or select element has an associated label that clearly describes its purpose. This allows screen readers to announce the input meaningfully and helps keyboard-only users understand what information is expected.

In addition to labeling, form accessibility includes:
- Providing clear error messages when input is invalid
- Ensuring error messages are announced to assistive technologies
- Maintaining logical focus order so users can navigate inputs easily
Bad Example:
Why this isn't good:
- This input relies only on a placeholder for context
- Screen readers may not announce the purpose of the field clearly
- Once a user starts typing, the placeholder disappears, leaving no guidance
- Keyboard-only users may not have enough context to know what to enter
Good Example:
```
Name
```
Why this is better:
- The is explicitly associated with the input via htmlFor / id
- Screen readers announce "Name" before the input, providing clear context
- Users navigating with Tab understand the field’s purpose
- The label persists even when the user types, unlike a placeholder
Error Handling:
```
Name



  Name is required
```
Explanation
- aria-describedby links the input to the error message using the element’s id
- Screen readers announce the error message when the input is focused
- aria-invalid="true" indicates that the field currently contains an error
- role="alert" ensures the error message is announced immediately when it appears
This creates a clear relationship between the input and its validation message, improving usability for screen reader users.

Tip: Only apply aria-invalid and error messages when validation fails. Avoid marking fields as invalid before user interaction.

Responsive Typography and Images

Responsive typography and images ensure that your content remains readable and visually appealing across a wide range of devices, from small smartphones to large desktop monitors.

This is important, because text should scale naturally so it remains legible on all screens, and images should adjust to container sizes to avoid layout issues or overflow. Both contribute to a better user experience and accessibility

In this section, we’ll cover practical ways to implement responsive typography and images in React and CSS.
```
h1 {
  font-size: clamp(1.5rem, 2vw, 3rem);
}
```
In this code:
- The clamp() function allows text to scale fluidly:
- The first value (1.5rem) is the “minimum font size”
- The second value (2vw) is the “preferred size based on viewport width”
- The third value (3rem) is the “maximum font size”
- This ensures headings are “readable on small screens” without becoming too large on desktops
Alternative methods include using media queries to adjust font sizes at different breakpoints

Responsive Images:
In this code, responsive images adapt to different screen sizes and resolutions to prevent layout issues or slow loading times. Key techniques include:

1. Fluid images using CSS:
```
img {
     max-width: 100%;
     height: auto;
   }
```
This makes sure that images never overflow their container and maintains aspect ratio automatically.

2. Using srcset for multiple resolutions:
This provides different image files depending on screen size or resolution and reduces loading times and improves performance on smaller devices.

3. Always include descriptive alt text

This is critical for screen readers and accessibility. It also helps users understand the image if it cannot be loaded.

Tip: Combine responsive typography, images, and flexible layout containers (like CSS Grid or Flexbox) to create interfaces that scale gracefully across all devices and maintain accessibility.

4. Ensure Sufficient Color Contrast

Low contrast text can make content unreadable for many users.
```
.bad-text {
  color: #aaa;
}

.good-text {
  color: #222;
}
```
Use tools like WebAIM Contrast Checker and Chrome DevTools Accessibility panel to check your color contrasts. Also note that WCAG AA requires 4.5:1 contrast ratio for normal text.

Building a Fully Accessible Responsive Component (End-to-End Example)

To understand how responsiveness and accessibility work together in practice, let’s build a reusable accessible card component that adapts to screen size and supports keyboard and screen reader users.

Step 1: Component Structure (Semantic HTML)
```
function ProductCard({ title, description, onAction }) {
  return (
    
      {title}
      {description}
      
    
  );
}
```
Why This Works
- provides semantic meaning for standalone content
- establishes a proper heading hierarchy
Step 2: Responsive Styling
```
.card {
  padding: 16px;
  border: 1px solid #ddd;
  border-radius: 8px;
}

@media (min-width: 768px) {
  .card {
    padding: 24px;
  }
}
```
This ensures comfortable spacing on mobile and improved readability on larger screens.

Step 3: Accessibility Enhancements
The visible button text provides a clear and accessible label, so no additional ARIA attributes are needed.

Step 4: Keyboard Focus Styling
```
button:focus {
  outline: 2px solid blue;
  outline-offset: 2px;
}
```
Focus indicators are essential for keyboard users.

Step 5: Using the Component
```
function App() {
  return (
    
       alert('Clicked')}
      />
    
  );
}
```
Key Takeaways

This simple component demonstrates:
- Semantic HTML structure
- Responsive design
- Built-in accessibility via native elements
- Minimal ARIA usage
In real-world applications, this pattern scales into entire design systems.

Testing Accessibility

Accessibility should be validated continuously, not just at the end of development. There are various automated tools you can use to help you with this process:
- Lighthouse (built into Chrome DevTools)
- axe DevTools for detailed audits
- ESLint plugins for accessibility rules
Manual Testing

But automated tools cannot catch everything. Manual testing is essential to make sure users can navigate using only the keyboard and use a screen reader (NVDA or VoiceOver. You should also test zoom levels (up to 200%) and check the color contrast manually.

Example: ESLint Accessibility Plugin
```
npm install eslint-plugin-jsx-a11y --save-dev
```
This helps catch accessibility issues during development.

Best Practices
- Use semantic HTML first
- Avoid unnecessary ARIA
- Test keyboard navigation
- Design mobile-first
- Ensure color contrast
- Use consistent spacing
When NOT to Overuse Accessibility Features
- Avoid adding ARIA when native HTML works
- Do not override browser defaults unnecessarily
- Avoid complex custom components without accessibility support
Future Enhancements
- Design systems with accessibility built-in
- Automated accessibility testing in CI/CD
- Advanced focus management libraries
- Accessibility-first component libraries
Conclusion

Building responsive and accessible React applications is not a one-time effort—it is a continuous design and engineering practice. Instead of treating accessibility as a checklist, developers should integrate it into the core of their component design process.

If you are starting out, focus on using semantic HTML and mobile-first layouts. These two practices alone solve a large percentage of accessibility and responsiveness issues. As your application grows, introduce ARIA enhancements, keyboard navigation, and automated accessibility testing.

The key is to build interfaces that work for everyone by default. When responsiveness and accessibility are treated as first-class concerns, your React applications become more usable, scalable, and future-proof.

How to Use HTML Attributes to Make Your Websites and Apps More Accessible

Elizabeth Lola — Fri, 06 Sep 2024 20:04:11 +0000

Have you ever used an attribute in HTML without fully understanding its purpose? You're not alone! Over time, I've dug into the meaning behind many HTML attributes, especially those that are crucial for accessibility.

In this in-depth tutorial, I'll break down some key HTML attributes that enhance accessibility, explaining what they do, and when to use them effectively.

Prerequisites

To follow along with this tutorial, you should have a basic understanding of HTML and a little bit of Javascript knowledge as well.

What are ARIA Attributes?
The alt Attribute
The aria-label Attribute
- Best practices for Using aria-label
The aria-labelledby Attribute
- How is aria-label Different from aria-labelledby?
- Best Practices for Using aria-labelledby
The aria-describedby Attribute
- Best Pracices for Using aria-describedby
The role Attribute
- Common role Values
- Best Practices for Using the role Attribute
The aria-controls Attribute
- Best Practices for Using aria-controls
The aria-selected Attribute
- Best Practices for Using aria-selected
The tabindex Attribute
- Possible tabindex Values
- Best Practices for Using tabindex
The title Attribute
- Accessibility Concerns with title
- Best Practices for Using the title Attribute
Using the for Attribute in label
- Best Practices for Using the for Attribute
The scope Attribute
- Possible scope Values
- Best Practices for Using scope
The aria-hidden Attribute
- Best Practices for Using aria-hidden
The inert Attribute
- Best Practices for Using inert
The aria-live Attribute
- Possible Values for aria-live
- Best Practices for Using aria-live
The aria-roledescription Attribute
- Best Practices for Using aria-roledescription
The aria-atomic Attribute
- Best Practices for Using aria-atomic
Conclusion

What Are ARIA Attributes?

Most of the attributes listed in this article are ARIA attributes. ARIA, which stands for Accessible Rich Internet Applications, is a set of attributes defined by the W3C (World Wide Web Consortium) to enhance the accessibility of web applications.

ARIA attributes provide additional information to assistive technologies like screen readers. Using them correctly can make complex web applications more accessible to individuals with visual, auditory, or motor impairments.

One key principle of using ARIA is that sometimes it's best not to use it. Although this might seem contradictory, you should only ARIA attributes when necessary. Overusing ARIA can disrupt the experience for users relying on assistive technologies. While sighted users might not notice any issues, excessive or improper use of ARIA can negatively impact accessibility.

The `alt` Attribute

The alt attribute likely isn't new to you if you've used HTML images. You use it to provide alternative text that displays when an image isn't properly shown on the screen.

But the most important use of the alt attribute is for accessibility. If the alt attribute is not present in an image element, then a screen reader may announce the name of the image file or the URL of the image instead of explaining what it's showing. This can be unhelpful and we don't want that.

The content in the alt attribute should be concise because its primary purpose is to briefly describe an image for those who cannot see it. This includes users who rely on screen readers, search engines, and users with slow internet connections where images may not load. If the alt text is too long, it may include unnecessary details that don't add value to the user's understanding.

The alt attribute is different from an image caption. Captions are visible and can provide more context or additional information about an image. Using a caption as alt text can make it too long and redundant.

If the image is purely decorative, then the alt attribute should be left empty. If an image has an empty alt attribute, an assistive tool will skip it. This is important to help keep users focused on the content and not distract them with unnecessary information.

Here's an example of how you can use the alt attribute:

<p>Lions are remarkable for their powerful roars, 
which can be heard up to five miles away. 
These roars are used to communicate with other 
members of the pride, as well as to ward off rival lions and intruders. 
Although lions are often associated with the African savannah, 
a small population of Asiatic lions still exists in India's Gir Forest, 
making them one of the world's most endangered big cats.p>

<img src="lion.jpg" alt="a lion" /> 

<img src="background-stars.png" alt="" />

The `aria-label` Attribute

The aria-label attribute is used to provide an accessible name to an element that might not have visible text. A common example of this is a button that contains an image or SVG.

A lot of elements have an accessible name – the accessible name is the content inside the element. The accessible name for the heading in this example is "Frequently Asked Questions"

<h1>Frequently Asked Questionsh1>

Everyone, including people using assistive technology, would clearly understand the meaning of the example above because it contains visible content.

But in the example below, a user relying on a screen reader might miss the content in the button if it doesn't have an aria-label. This is because the content in the button is an SVG and the SVG does not contain any visible content:

<button aria-label="Search">
    <svg
      fill="#000000" 
      height="20px"
      width="20px"
      xmlns="http://www.w3.org/2000/svg" 
      viewBox="0 0 488.4 488.4">
        <g stroke-width="0">g>
        <g stroke-linecap="round" stroke-linejoin="round">g>
        <g><g>
        <g>
          <path d="M0,203.25c0,112.1,91.2,203.2,203.2,203.2c51.6,0,98.8-19.4,134.7-51.2l129.5,129.5c2.4,2.4,5.5,3.6,8.7,3.6 s6.3-1.2,8.7-3.6c4.8-4.8,4.8-12.5,0-17.3l-129.6-129.5c31.8-35.9,51.2-83,51.2-134.7c0-112.1-91.2-203.2-203.2-203.2 S0,91.15,0,203.25z M381.9,203.25c0,98.5-80.2,178.7-178.7,178.7s-178.7-80.2-178.7-178.7s80.2-178.7,178.7-178.7 S381.9,104.65,381.9,203.25z" />
        g> 
        g>g>
    svg>
button>

Do not overuse the aria-label. Not all content needs an aria-label – for example, if you have a button that contains an image with alt, or an SVG with a title, then those attributes act as the accessible name for that element.

<button>
    <img src="search-icon.png" alt="Search" /> 
button>



<button>
  <svg
    fill="#000000"
    height="20px"
    width="20px"
    role="image"
    xmlns="http://www.w3.org/2000/svg"
    viewBox="0 0 488.4 488.4">
        <title>Search Icontitle> 
        <g stroke-width="0">g>
        <g stroke-linecap="round" stroke-linejoin="round">g>
        <g><g>
        <g>
         <path d="M0,203.25c0,112.1,91.2,203.2,203.2,203.2c51.6,0,98.8-19.4,134.7-51.2l129.5,129.5c2.4,2.4,5.5,3.6,8.7,3.6 s6.3-1.2,8.7-3.6c4.8-4.8,4.8-12.5,0-17.3l-129.6-129.5c31.8-35.9,51.2-83,51.2-134.7c0-112.1-91.2-203.2-203.2-203.2 S0,91.15,0,203.25z M381.9,203.25c0,98.5-80.2,178.7-178.7,178.7s-178.7-80.2-178.7-178.7s80.2-178.7,178.7-178.7 S381.9,104.65,381.9,203.25z" />
        g> 
        <g><g>
  svg>
button>

You should use the aria-label sparingly and appropriately. Overusing the attribute can lead to several issues:

The aria-label content is not visible to sighted users. If a user with a cognitive disability is using a screen reader for support, they might not understand why they’re hearing different information from what they see on the screen.
Using aria-label extensively across a large codebase can make the HTML harder to maintain. You may struggle to track where labels are coming from, especially if they’re set programmatically or in multiple places.

Best Practices for Using `aria-label`

Whenever possible, use visible text labels. They’re easier to understand and maintain, and they ensure consistent experiences for all users.
When Possible: If there is already a visible label on the page, use aria-labelledby to link the element to the existing text instead of creating a new label with aria-label (we'll talk about this below).
If you use aria-label, keep the text short and to the point. It should describe the element’s purpose in as few words as possible.

The `aria-labelledby` Attribute

The aria-labelledby attribute is used to associate an element with another element that serves as its label. It links the target element to one or more other elements on the page that contain the text that should be used as the label.

You can use this attribute when there is already a visible text label or when the label needs to be composed of multiple text elements.

For example, you can use aria-labelledby in a

element to associate it with a heading or other text that serves as a label for the entire section.

<h2 id="about-heading">About Ush2> 
<section aria-labelledby="about-heading"> 
    <p>We are a company dedicated to providing excellent service...p>
section>

<h2 id="services-heading">Our Servicesh2>
<section aria-labelledby="services-heading">
    <p>We offer a wide range of services including...p>
section>

Sometimes, you might want to combine multiple pieces of text as the label. You can do this by listing multiple IDs in the aria-labelledby attribute:

<h1 id="dialog-title">Confirmation Requiredh1>
<p id="dialog-description">Are you sure you want to delete this item?p>
<button aria-labelledby="dialog-title dialog-description">Yesbutton>

The aria-labelledby is similar to the aria-label in that its purpose is to provide an accessible element.

How is `aria-label` Different from `aria-labelledby`?

aria-label directly assigns a string of text as a label for an element. This text is not visible on the screen but is announced by assistive technologies like screen readers. It’s typically used when there is no visible text label.

aria-labelledby points to one or more existing elements on the page (using their id attributes) that should be used as the label for the element. The label text is visible to all users because it’s part of the content of another element.

Best Practices for Using `aria-labelledby`

Use aria-labelledby over aria-label when there is already text on the page that can serve as the label. This reduces redundancy and ensures that both sighted users and screen reader users see the same content.
The id attributes referenced by aria-labelledby must be unique on the page and correctly point to existing elements. If the ID is missing or incorrect, the label won’t work, leading to accessibility issues.
When combining multiple labels, ensure that the resulting label makes sense when read together. The order of IDs in aria-labelledby matters, as screen readers will read the labels in the order they are listed.
Like aria-label, avoid overusing aria-labelledby in situations where a simpler approach (like using a visible label element directly) would suffice. This helps keep the code maintainable and reduces the cognitive load for users.

The `aria-describedby` Attribute

The aria-describedby attribute is used to associate an element with one or more elements that provide additional descriptive information about it. The aria-describedby attribute is used to provide additional context or instructions to an element.

Unlike aria-labelledby, which is meant to provide a label or name, aria-describedby is intended to give users more detailed information or context about an element, often to supplement what they already know from the label.

<label id="full-name">Full namelabel>
<input type="text" aria-labelledby="full-name" aria-describedby="info">
<span id="info">Enter your full name.span>

When both aria-labelledby and aria-describedby are used on the same element, screen readers will first announce the label (from aria-labelledby), then the role of the element (for example, "button"), and finally the description (from aria-describedby).

Best Practices for Using `aria-describedby`

Apply aria-describedby when you need to provide users with additional context or instructions that go beyond the label. This is particularly useful for forms, complex controls, or any element that might require clarification.
While aria-describedby is meant for more detailed descriptions, avoid overly long text. Keep the description focused on what the user needs to know to interact with the element effectively.
Just like with aria-labelledby, ensure that the elements referenced by aria-describedby have unique and relevant id attributes. The content of these elements should be directly relevant to the element they describe.

The `role` Attribute

The role attribute is used to specify the role of an element. You can use it to override the default role of a semantic element. It helps assistive technologies understand how an element should be interpreted or interacted with.

When using non-semantic elements (like

or ) to create interactive controls (buttons, dialogs, tabs, and so on), the role attribute informs assistive technologies of the element’s intended behavior. You can also use the role to define landmark roles that assist in navigation, such as banner or complementary, which defines the structure of the page for screen reader users.

Common `role` Values

Roles for Landmark Regions:

banner: Represents the site header.
navigation: Defines a navigation section of the page, often for site or page navigation links.
main: Marks the main content of a document, distinct from sidebars, footers, and so on.
contentinfo: Represents the footer information.

This example below is just for demonstration purposes – you should use the right semantic element when possible:

<div role="banner">
    <h1>My Websiteh1>
div>

<div role="navigation">
    <ul>
        <li><a href="#home">Homea>li>
        <li><a href="#about">Abouta>li>
    ul>
div>

<div role="main">
    <h2>Welcome to My Websiteh2>
    <p>Here is some main content...p>
div>

<div role="contentinfo">
    <p>© 2024 My Websitep>
div>

Roles for Widgets and Interactive Elements:

button: Represents a button element, which users can click to trigger an action.
dialog: Marks a dialog box or modal that requires user interaction.
alert: Identifies an element as an important message or alert that requires user attention.
tablist, tab, tabpanel: Used for tabbed interfaces, where tablist contains the tabs, and each tab controls the visibility of its corresponding tabpanel.

<div role="button" tabindex="0" onclick="submitForm()">Submitdiv>

<div role="dialog" aria-labelledby="dialog-title" aria-modal="true">
    <h2 id="dialog-title">Confirmationh2>
    <p>Are you sure you want to proceed?p>
    <button onclick="closeDialog()">Closebutton>
div>

Example of Tabbed panel:

<div role="tablist" aria-label="Sample Tabs">
    <button role="tab" id="tab-1" aria-controls="panel-1" aria-selected="true" tabindex="0">Tab 1button>
    <button role="tab" id="tab-2" aria-controls="panel-2" aria-selected="false" tabindex="-1">Tab 2button>
    <button role="tab" id="tab-3" aria-controls="panel-3" aria-selected="false" tabindex="-1">Tab 3button>
div>

<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
    <h2>Content for Tab 1h2>
    <p>This is the content of the first tab.p>
div>

<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
    <h2>Content for Tab 2h2>
    <p>This is the content of the second tab.p>
div>

<div role="tabpanel" id="panel-3" aria-labelledby="tab-3" hidden>
    <h2>Content for Tab 3h2>
    <p>This is the content of the third tab.p>
div>

Best Practices for Using the `role` Attribute

Always prefer using native HTML elements that already have the appropriate role (for example,
Don't overuse or misuse the role attribute as this can lead to confusion and reduced accessibility. Use role to enhance or clarify when needed, not to replace semantic HTML.
Understand implicit roles. Many HTML elements have implicit roles. For example, an element with an href attribute automatically has the link role. Avoid adding redundant role attributes to these elements.

The `aria-controls` Attribute

The aria-controls attribute informs a screen reader that the element is controlled or affected by another element. It's commonly used to indicate that a component (like a button or a tab) controls or interacts with another part of the page (like a panel or a menu). It is also used in interactive components such as tabs, accordions, and sliders to describe which parts of the page are affected when the user interacts with the component.

For example, you can use aria-controls on a tab button to indicate which panel each button controls:


<button id="tab1" aria-controls="panel1">Tab 1button>
<button id="tab2" aria-controls="panel2">Tab 2button>


<div id="panel1" role="tabpanel">Content for Tab 1div>
<div id="panel2" role="tabpanel">Content for Tab 2div>

Best Practices for Using `aria-controls`

Ensure that the ID used in aria-controls matches the id of the controlled element exactly.
Use aria-controls in conjunction with role and state attributes like aria-selected, or role="tabpanel" to provide more complete information about the controlled elements and their states.
Apply aria-controls to interactive elements such as buttons or links that have a direct effect on other elements. It is not typically used for non-interactive content.

The `aria-selected` Attribute

The aria-selected attribute is used to indicate the current selection state of an element within a group of selectable items. A selectable item could be an option in a menu, a tab in a tabbed panel, or an item in a list box.

Here's an example of the selection state in a list box. aria-selected="true" in option 1 indicates that Option 1 is currently selected.


<ul role="listbox">
  <li role="option" aria-selected="true">Option 1li>
  <li role="option" aria-selected="false">Option 2li>
  <li role="option" aria-selected="false">Option 3li>
ul>

Best Practices for Using `aria-selected`

Use aria-selected="true" for the selected item and aria-selected="false" for non-selected items. The value should be a string, not a boolean.
Ensure that the visual state of the element (for example, active tab or selected option) matches the aria-selected value. Inconsistent states can lead to confusion for users of assistive technologies.
Use aria-selected in conjunction with appropriate role attributes (for example, role="option" for listbox items) to provide complete context.
Ensure that aria-selected is updated dynamically as users interact with the interface. For example, when a user selects a new option, update the aria-selected attribute accordingly.

The `tabindex` Attribute

The tabindex attribute is used to control the keyboard navigation of an element. You can use it to activate focus for non-interactive elements like div, p, or span or disable focus for interactive elements like button, a, input. You can also use it to control focus order on a page.

Possible `tabindex` Values

Positive values: Elements with positive values become focusable and are included in the tab order with their numbers determining the order in which they are focused. Elements with lower numbers are focused before elements with higher numbers.

<button tabindex="2">Cancelbutton> 
<button tabindex="1">Submitbutton>

Elements with the same values will be navigated in the order in which they appear.

Note: Using positive tabindex values can lead to a confusing and non-intuitive tab order. It is generally better to use tabindex="0" for elements that should be part of the natural tab order.

Zero: You use this to make an element focusable and include it in the natural tab order based on its position in the document. It's useful for making elements focusable that are not normally focusable (like

or ).

<div role="button" tabindex="0">Submitdiv>

Negative values: You use this to remove an element from the tab order, meaning it cannot be focused using the Tab key. But it can still be focused programmatically (via JavaScript). It's useful for elements that should not be focusable by default but may need to be focusable under certain conditions.

<input type="text" name="name">
<input type="text" name="other-names" tabindex="-1">
<input type="text" placeholder="email">

Best Practices for Using `tabindex`

Rely on the natural tab order as much as possible. Use tabindex="0" to include elements in the tab order and avoid using positive values unless absolutely necessary.
Using positive tabindex values can create an unpredictable tab order and make it harder for users to navigate. It's better to use the default flow and tabindex="0".
Use tabindex="-1" for elements not intended to be focused.
Ensure that the focus order follows a logical and intuitive sequence, which matches the visual layout and interaction flow of the page.
Test with keyboard and assistive technologies.
When dynamically adding or removing focusable elements (for example, through JavaScript), ensure that focus management is handled properly to maintain a smooth experience.

The `title` Attribute

The title attribute in HTML is used to provide additional information about an element. The content in the attribute shows in a tooltip when a user hovers over the element containing the title. It can be applied to most HTML elements, including links, images, and form fields.

You can use the title attribute to provide a brief explanation or description of the content of an element. For example, you can use it to clarify the meaning of abbreviations or acronyms when used with the tag.

<abbr title="World Wide Web">WWWabbr>


<img src="logo.png" 
alt="Company Logo" 
title="This is the logo of our company">

Accessibility Concerns with the `title` Attribute

The title attribute can be useful, but it comes with some accessibility concerns:

Screen readers do not consistently announce the title attribute, especially when there is also an alt attribute – or they may ignore it altogether. Users of assistive technologies may miss out on the information provided by the title attribute, especially if they rely solely on screen readers.
The tooltip generated by the title attribute typically appears only on hover with a mouse or trackpad. Users who navigate with a keyboard or touch screen may not have access to this information.
The content of the title attribute is hidden by default and only revealed on hover. This makes it less accessible to users who don't know they need to hover to get additional information.
Tooltips can be difficult to read because they often disappear quickly, and their content might be truncated or too long to fit within the tooltip window.

Best Practices for Using the `title` Attribute

Avoid relying solely on the title attribute. Ensure that critical information is available in a more accessible manner, such as visible text or ARIA attributes.
Use the title attribute for supplementary, non-essential information that enhances user experience but isn’t critical to understanding the content.
For form inputs, use the aria-describedby attribute to associate additional instructions with a form element. Use visible labels or descriptions instead of or in addition to the title attribute to ensure that all users have access to the information.
If you use the title attribute, keep the text brief and to the point. Long tooltips can be difficult to read and may get truncated.

Using the `for` Attribute in `label`

The for attribute, when used in , is used to connect a label to its corresponding form control element – that is , </code>. Screen readers will announce the label when the assigned input is focused. When used correctly, clicking on the label will focus on the corresponding input. The value of the <code>for</code> attribute should match the <code>id</code> of the input it is associated with: <pre><code class="lang-xml"><label for="fullname">Full Name</label> <input type="text" id="fullname">  </code></pre> <h3 id="heading-best-practices-for-using-the-for-attribute">Best Practices for Using the <code>for</code> Attribute</h3> <ul> <li>Ensure that each form control has a unique <code>id</code> attribute so that the <code>for</code> attribute can correctly reference it. Avoid using duplicate <code>id</code> values on the same page. </li> <li>Avoid empty <code>for</code> attributes. If there’s no associated form control, it can confuse users of assistive technologies. </li> <li>Position labels close to their associated form controls. Typically, labels should be placed above or to the left of the form controls for optimal readability and usability. </li> </ul> <h2 id="heading-the-scope-attribute">The <code>scope</code> Attribute</h2> The <code>scope</code> attribute is used in HTML tables to define the relationship between table headers and the cells they describe. The attribute is particularly important for accessibility because it helps screen readers and other assistive technologies understand the structure of the table and convey the correct information to users. The <code>scope</code> attribute is applied to <code><th></code> (table header) elements to specify whether the header applies to a row, a column, or a group of rows or columns <h3 id="heading-possible-scope-values">Possible <code>scope</code> Values</h3> <ul> <li><code>row</code>: Indicates that the <code><th></code> element is a header for a row. In the example below, <code>scope="row"</code> is used for the first <code><th></code> element in each row, indicating that the header applies to the entire row.</li> </ul> <pre><code class="lang-xml"><table> <tbody> <tr> <th scope="row">Product A</th> <td>$1000</td> <td>$1200</td> <td>$1100</td> </tr> <tr> <th scope="row">Product B</th> <td>$900</td> <td>$950</td> <td>$1000</td> </tr> </tbody> </table> </code></pre> <ul> <li><code>col</code>: Indicates that the <code><th></code> element is a header for a column.</li> </ul> <pre><code class="lang-xml"><table> <thead> <tr> <th scope="col">Name</th> <th scope="col">Age</th> <th scope="col">Occupation</th> </tr>  </thead> <tbody> <tr> <td>Jane</td> <td>30</td> <td>Engineer</td> </tr> <tr> <td>Tobe</td> <td>25</td> <td>Designer</td> </tr> </tbody> </table> </code></pre> <ul> <li><code>rowgroup</code>: Indicates that the <code><th></code> element is a header for a group of rows. In the example below, the rows "Marketing Department" and "Sales Department" have the <code>scope="rowgroup"</code> attribute to indicate that these rows act as headers for the groups of rows that follow:</li> </ul> <pre><code class="lang-xml"><table> <thead> <tr> <th scope="col">Department</th> <th scope="col">Employee Name</th> <th scope="col">Position</th> <th scope="col">Salary</th> </tr> </thead> <tbody>  <tr> <th scope="rowgroup" colspan="4">Marketing Department</th> </tr> <tr> <th scope="row">Amari Pere</th> <td>Marketing Manager</td> <td>$75,000</td> </tr> <tr> <th scope="row">Uyati Hope</th> <td>SEO Specialist</td> <td>$65,000</td> </tr>  <tr> <th scope="rowgroup" colspan="4">Sales Department</th> </tr> <tr> <th scope="row">Timini Prosper</th> <td>Sales Manager</td> <td>$80,000</td> </tr> <tr> <th scope="row">Delilu Pink</th> <td>Account Executive</td> <td>$70,000</td> </tr> </tbody> </table> </code></pre> <ul> <li><code>colgroup</code>: Indicates that the <code><th></code> element is a header for a group of columns. In the example below, <code>scope="colgroup"</code> is used to indicate that the first row of headers applies to groups of columns (Q1 and Q2), while <code>scope="col"</code> and <code>scope="row"</code> are used for individual columns and rows.</li> </ul> <pre><code class="lang-xml"><table> <thead> <tr> <th scope="colgroup">Region</th> <th scope="colgroup">Q1</th> <th scope="colgroup">Q2</th> </tr> <tr> <th scope="col">Sales</th> <th scope="col">Profit</th> <th scope="col">Sales</th> <th scope="col">Profit</th> </tr> </thead> <tbody> <tr> <th scope="row">North</th> <td>$2000</td> <td>$400</td> <td>$2500</td> <td>$500</td> </tr> <tr> <th scope="row">South</th> <td>$1500</td> <td>$300</td> <td>$1800</td> <td>$350</td> </tr> </tbody> </table> </code></pre> <h3 id="heading-best-practices-for-using-the-scope-attribute">Best Practices for Using the <code>scope</code> Attribute</h3> <ul> <li>Always define <code>scope</code> for complex tables to clarify the relationship between headers and data cells. </li> <li>Simplify table structures when possible. While the <code>scope</code> attribute helps with accessibility, consider simplifying table structures where possible. If a table is too complex, it might be difficult for all users to understand, even with proper markup. </li> <li>For particularly complex tables, consider using ARIA attributes like <code>aria-labelledby</code> or <code>aria-describedby</code> to provide additional context and ensure that all users can navigate the table effectively. </li> <li>After applying the <code>scope</code> attribute, test the table with screen readers to ensure that the relationships between headers and data cells are announced correctly. </li> <li>Don’t use <code>scope</code> in situations where it’s unnecessary. For simple tables where each header is clearly associated with a single row or column, HTML’s default behavior is usually sufficient. </li> </ul> <h2 id="heading-the-aria-hidden-attribute">The <code>aria-hidden</code> Attribute</h2> The aria-hidden attribute is used to control the visibility of an element for assistive technologies while it's still visible on the screen. You can use it to hide purely decorative elements, like icons or images, that don't add meaningful information to the content. This helps prevent screen readers from reading unnecessary information. <pre><code class="lang-xml"><button> <span aria-hidden="true">🔍</span> Search </button> </code></pre> You can also use it to hide content that has already been announced to prevent redundancy in what screen readers announce. For content that is toggled on and off (like modals, or expandable sections), you can use <code>aria-hidden</code> to hide the inactive content from screen readers, ensuring that they only interact with the visible, active content. <pre><code class="lang-xml"><button> <span aria-hidden="true">✉</span>  <span>Messages</span> </button> </code></pre> You can also use <code>aria-hidden</code> when creating complex widgets (like carousels or tabbed interfaces) to hide inactive panels or slides from assistive technologies, focusing their attention on the active part of the widget. <pre><code class="lang-xml"><div id="menu" aria-hidden="true">  </div> <button onclick="toggleMenu()">Toggle Menu</button> <script> const toggleMenu = () => { const menu = document.getElementById('menu'); const isHidden = menu.getAttribute('aria-hidden') === 'true'; menu.setAttribute('aria-hidden', !isHidden); } </script> </code></pre> <h3 id="heading-best-practices-for-using-aria-hidden">Best Practices for Using <code>aria-hidden</code></h3> <ul> <li>Only use <code>aria-hidden</code> when you need to hide content from screen readers to avoid overwhelming users with redundant or irrelevant information. </li> <li>Do not use on elements that users need to interact with, like buttons or links. </li> <li>Ensure that <code>aria-hidden</code> accurately reflects the visibility of elements on the screen. If an element becomes visible or hidden via JavaScript or CSS, update <code>aria-hidden</code> accordingly to maintain accessibility. </li> <li>In a team environment, document why and where <code>aria-hidden</code> is used in your codebase, so that other team members understand its purpose and can maintain it properly. </li> </ul> <h2 id="heading-the-inert-attribute">The <code>inert</code> Attribute</h2> The <code>inert</code> attribute prevents an element and all of its descendants from being focusable, interactive, or perceivable by assistive technologies. When an element has the <code>inert</code> attribute, it cannot receive focus, be clicked on, or be interacted with in any way. It's also hidden from assistive technologies like screen readers. Unlike <code>aria-hidden</code>, which only affects accessibility, <code>inert</code> applies to all user interactions. The inert attribute can be used to disable sections of a page that are temporarily irrelevant, such as during form validation errors, while loading data, or when a certain section is hidden but still in the DOM. It can also be used in complex user interfaces like multi-step forms or wizards to ensure that users only interact with the current step or section The most common use of inert, however, is in a modal, where you want to prevent users from interacting with the background content while the modal is open. Like in the example below, when the modal is open the <code>inert</code> attribute is added to the main content, making it non-interactive and hidden from screen readers. When the modal is closed, the <code>inert</code> attribute is removed, and the main content becomes interactive again. <pre><code class="lang-xml"><div id="main-content" inert> <p>This is the main content of the page. It will be inactive when the modal is open.</p> </div> <div id="modal" role="dialog" aria-modal="true"> <h2>Modal Title</h2> <p>This is the content inside the modal.</p> <button onclick="closeModal()">Close Modal</button> </div> <script> function openModal() { document.getElementById('main-content').setAttribute('inert', ''); document.getElementById('modal').style.display = 'block'; } function closeModal() { document.getElementById('main-content').removeAttribute('inert'); document.getElementById('modal').style.display = 'none'; } </script> </code></pre> <h3 id="heading-best-practices-for-using-the-inert-attribute">Best Practices for Using the <code>inert</code> Attribute</h3> <ul> <li>Ensure that when you use <code>inert</code>, the visually inactive or disabled state of elements is clear to sighted users. For example, dimming or blurring background content when a modal is open can complement the <code>inert</code> attribute. </li> <li>Don't overuse <code>inert</code>, as doing so might unintentionally make significant portions of your page non-interactive and inaccessible. Use it judiciously to manage user focus and interaction only when necessary. </li> <li>When dynamically adding and removing the <code>inert</code> attribute, ensure that it is properly removed when no longer needed so that users can regain access to previously disabled content. </li> </ul> <h2 id="heading-the-aria-live-attribute">The <code>aria-live</code> Attribute</h2> You can use the <code>aria-live</code> attribute to notify assistive technologies about dynamic content changes on a webpage. When <code>aria-live</code> is applied to an element, screen readers are alerted when the content inside that element is updated, ensuring that users are informed about important changes that occur after the page has initially loaded. This attribute can be useful for content that updates dynamically, such as notifications, alerts, chat messages, or stock prices. It ensures that users are aware of changes that might otherwise go unnoticed. <h3 id="heading-possible-values-for-aria-live">Possible Values for <code>aria-live</code></h3> There are three main values: <code>off</code>, <code>polite</code>, and <code>assertive</code>. <ul> <li><code>off</code>: Default value, updates to the element will not be announced by screen readers. </li> <li><code>polite</code>: Updates will be announced by the screen reader, but only after the user has finished interacting with the current task or reading other content. This ensures that the update does not interrupt the user’s current activity. </li> </ul> In the example below, each new message is added to the <code>#messages</code> container, which has <code>aria-live="polite"</code>. The screen reader will announce the new message only after the user finishes their current activity. <pre><code class="lang-xml"><div id="chat-window"> <div id="messages" aria-live="polite">  <div>John: Hello!</div> <div>You: Hi there!</div> </div> </div> <button onclick="addMessage()">Send Message</button> <script> function addMessage() { const newMessage = document.createElement('div'); newMessage.textContent = 'Alice: How are you?'; document.getElementById('messages').appendChild(newMessage); } </script> </code></pre> <ul> <li><code>assertive</code>: Updates will be announced immediately, interrupting whatever the screen reader is currently announcing. Use this for urgent or critical information that requires the user’s immediate attention.</li> </ul> In the example below, updates to the stock prices are placed within a container that has <code>aria-live="assertive"</code>. <pre><code class="lang-xml"><div id="stock-ticker" aria-live="assertive">  <div id="stock1">Stock A: $100</div> <div id="stock2">Stock B: $150</div> </div> <button onclick="updateStockPrices()">Update Prices</button> <script> function updateStockPrices() { document.getElementById('stock1').textContent = 'Stock A: $95'; document.getElementById('stock2').textContent = 'Stock B: $155'; } </script> </code></pre> <h3 id="heading-best-practices-for-using-aria-live">Best Practices for Using <code>aria-live</code></h3> <ul> <li>Use <code>aria-live="polite"</code> for non-critical updates to avoid disrupting the user’s experience. Reserve <code>aria-live="assertive"</code> for urgent updates that require immediate attention, such as critical errors or security warnings. </li> <li>Be mindful of how often you use <code>aria-live</code> elements on a page. Overusing it can lead to an overstimulating experience for users who rely on screen readers, as they may be overwhelmed by frequent announcements. </li> <li>Don’t use <code>aria-live</code> on content that doesn’t need to be announced, or on content that’s already being communicated to the user in another way. </li> <li><code>aria-live</code> is particularly useful for content that is updated dynamically, such as live sports scores, breaking news, or chat applications. Make sure that the user is kept informed of important updates as they occur. </li> </ul> <h2 id="heading-the-aria-roledescription-attribute">The <code>aria-roledescription</code> Attribute</h2> You can use <code>aria-roledescription</code> to provide a human-readable, localized description for the role of an element. It overrides the implicit or explicit <code>role</code> value for screen readers, and allows developers to create more intuitive and context-specific descriptions for complex or unconventional user interface components that may not have a standard role name. You can use it to provide a clearer explanation of the element’s purpose or functionality. In the example below, screen readers will announce it as "Bookmark Button" instead of just "Button." <pre><code class="lang-xml"><button role="button" aria-roledescription="Bookmark Button"> <span aria-hidden="true">⭐</span> Save this page </button> </code></pre> You can also use it to support internationalization, like providing role descriptions in different languages. <pre><code class="lang-xml"><button role="button" aria-roledescription="Search Button" lang="en"> <span aria-hidden="true">🔍</span> Search </button> <button role="button" aria-roledescription="Botón de busqueda" lang="es"> <span aria-hidden="true">🔍</span> Buscar </button> <button role="button" aria-roledescription="Bouton de recherche" lang="fr"> <span aria-hidden="true">🔍</span> Recherche </button> </code></pre> <h3 id="heading-best-practices-for-using-aria-roledescription">Best Practices for Using <code>aria-roledescription</code></h3> <ul> <li>Only use <code>aria-roledescription</code> when the standard role does not sufficiently describe the element's purpose. </li> <li>The description should be short, clear, and directly related to the element's function. Avoid using jargon or overly technical language. </li> <li><code>aria-roledescription</code> should be used alongside an appropriate ARIA role, not as a replacement. The <code>role</code> provides the foundational context (like <code>"button"</code> or <code>"listbox"</code>), while the description adds clarity. </li> <li>If your application supports multiple languages, ensure that the <code>aria-roledescription</code> values are localized to match the user's language preferences. This helps provide a consistent and understandable experience. </li> <li>Ensure that the <code>aria-roledescription</code> does not repeat or conflict with other ARIA attributes or element labels. It should complement, not duplicate, the information already provided. </li> </ul> <h2 id="heading-the-aria-atomic-attribute">The <code>aria-atomic</code> Attribute</h2> You can use the <code>aria-atomic</code> attribute to control how updates to an element are announced by assistive technologies. When <code>aria-atomic</code> is set to <code>true</code>, it indicates that when changes occur within the element, the entire content of the element should be treated as a single unit and announced in full by the screen reader (rather than announcing only the changed parts). In cases where updates to part of an element might make the overall context unclear, <code>aria-atomic</code> helps by providing a full announcement of the element's content, giving users a complete understanding of the context. It is often used in conjunction with <code>aria-live</code>. While <code>aria-live</code> determines how updates are announced (politely or assertively), <code>aria-atomic</code> controls whether the entire content is read or just the changes. <pre><code class="lang-xml"><div id="news-ticker" role="region" aria-live="polite" aria-atomic="true"> Breaking News: Major storm expected this weekend. </div> <button onclick="updateHeadline()">Update Headline</button> <script> function updateHeadline() { document.getElementById('news-ticker').innerText = 'Breaking News: Stock market hits record high!'; } </script> </code></pre> <h3 id="heading-best-practices-for-using-aria-atomic">Best Practices for Using <code>aria-atomic</code></h3> <ul> <li>Apply <code>aria-atomic="true"</code> only to elements where a full announcement of updates is essential for understanding the context. </li> <li>When using <code>aria-atomic="true"</code>, ensure that the content within the element provides consistent and complete context to users. </li> <li>Use <code>aria-atomic</code> in combination with <code>aria-live</code> to specify how updates should be announced. This ensures that the updates are announced in the appropriate manner and with full context. </li> </ul> <h2 id="heading-conclusion">Conclusion</h2> Understanding and effectively using HTML attributes for accessibility is crucial for creating inclusive web experiences. By understanding and using these attributes appropriately, you can ensure that your application has a great user experience for all visitors. <h3 id="heading-resources">Resources</h3> <ul> <li><a target="_blank" href="https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/">Providing Accessible Names and Descriptions</a> </li> <li><a target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA">MDN ARIA</a> </li> <li><a target="_blank" href="https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/">No ARIA is better than Bad ARIA</a> </li> <li><a target="_blank" href="https://www.w3.org/WAI/ARIA/apg/example-index/#examples_by_props_label">ARIA examples by properties and states</a> </li> </ul> Thank you so much for reading, I hope this guide helps you create more accessible web content. If you found it helpful, consider sharing. You can connect with me on <a target="_blank" href="https://www.linkedin.com/in/elizabeth-meshioye/">LinkedIn</a>. </article> </main></body></html>

aria - freeCodeCamp.org

How to Build Responsive and Accessible UI Designs with React and Semantic HTML

Table of Contents

Prerequisites

Overview

Why Accessibility and Responsiveness Matter

Core Principles of Accessible and Responsive Design

1. Semantic HTML First

Key ARIA Attributes

1. role

2. aria-label

3. aria-hidden

4. aria-live

Keyboard Navigation

Avoiding Common Keyboard Traps

Focus Management

Best Practice:

Forms and Accessibility

Responsive Typography and Images

1. Fluid images using CSS:

2. Using srcset for multiple resolutions:

3. Always include descriptive alt text

4. Ensure Sufficient Color Contrast

Building a Fully Accessible Responsive Component (End-to-End Example)

Step 1: Component Structure (Semantic HTML)

{title}

establishes a proper heading hierarchy

Step 2: Responsive Styling

Step 3: Accessibility Enhancements

Step 4: Keyboard Focus Styling

Step 5: Using the Component

Testing Accessibility

Manual Testing

Best Practices

When NOT to Overuse Accessibility Features

Future Enhancements

Conclusion

How to Use HTML Attributes to Make Your Websites and Apps More Accessible

Prerequisites

Table of Contents

What Are ARIA Attributes?

The alt Attribute

The aria-label Attribute

Best Practices for Using aria-label

The aria-labelledby Attribute

How is aria-label Different from aria-labelledby?

Best Practices for Using aria-labelledby

The aria-describedby Attribute

Best Practices for Using aria-describedby

The role Attribute

Common role Values

Best Practices for Using the role Attribute

The aria-controls Attribute

Best Practices for Using aria-controls

The aria-selected Attribute

Best Practices for Using aria-selected

The tabindex Attribute

Possible tabindex Values

Best Practices for Using tabindex

The title Attribute

Accessibility Concerns with the title Attribute

Best Practices for Using the title Attribute

Using the for Attribute in label

2. Using `srcset` for multiple resolutions:

The `alt` Attribute

The `aria-label` Attribute

Best Practices for Using `aria-label`

The `aria-labelledby` Attribute

How is `aria-label` Different from `aria-labelledby`?

Best Practices for Using `aria-labelledby`

The `aria-describedby` Attribute

Best Practices for Using `aria-describedby`

The `role` Attribute

Common `role` Values

Best Practices for Using the `role` Attribute

The `aria-controls` Attribute

Best Practices for Using `aria-controls`

The `aria-selected` Attribute

Best Practices for Using `aria-selected`

The `tabindex` Attribute

Possible `tabindex` Values

Best Practices for Using `tabindex`

The `title` Attribute

Accessibility Concerns with the `title` Attribute

Best Practices for Using the `title` Attribute

Using the `for` Attribute in `label`