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.

Table of Contents

• 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 <div> or <span>.These elements provide built-in accessibility, improve SEO, and make code more readable.

For example:

Non-semantic:

<div onClick={handleClick}>Submit</div>

Semantic:

<button type="button" onClick={handleClick}>Submit</button>

Another example:

Non-semantic:

<div className="header">My App</div>

Semantic:

<header>My App</header>

Using semantic elements such as <header>, <nav>, <main>, <section>, <article>, and <button> helps browsers and assistive technologies (like screen readers) understand the structure and purpose of your UI without additional configuration.

Why this matters:

• Screen readers understand semantic elements automatically

• It supports built-in accessibility (keyboard, focus, roles)

• There's less need for ARIA attributes

• It gives you better SEO and maintainability

2. Mobile-First Design

Mobile-first design means starting your UI design with the smallest screen sizes (typically mobile devices) and progressively enhancing the layout for larger screens such as tablets and desktops.

This approach makes sure that core content and functionality are prioritized, layouts remain simple and performant, and users on mobile devices get a fully usable experience.

In practice, mobile-first design involves:

• Using a single-column layout initially

• Applying minimal styling and spacing

• Avoiding complex UI patterns on small screens

Then, you scale up using CSS media queries:

.container {
  display: flex;
  flex-direction: column;
}
@media (min-width: 768px) {
  .container {
    flex-direction: row;
  }
}

Here, the default layout is optimized for mobile, and enhancements are applied only when the screen size increases.

Why this approach works:

• Prioritizes essential content

• Improves performance on mobile devices

• Reduces layout bugs when scaling up

• Aligns with how most users access web apps today

3. Progressive Enhancement

Progressive enhancement is the practice of building a baseline user experience that works for all users (regardless of their device, browser capabilities, or network conditions) and then layering on advanced features for more capable environments.

This approach ensures that core functionality is always accessible, users on older devices or slow networks aren't blocked, and accessibility is preserved even when advanced features fail.

In practice, this means:

• Start with semantic HTML that delivers content and functionality

• Add basic styling with CSS for layout and readability

• Enhance interactivity using JavaScript (React) only where needed

For example, a form should still be usable with plain HTML:

<form>
  <label htmlFor="email">Email</label>
  <input id="email" type="email" />
  <button type="submit">Submit</button>
</form>

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)

<div onClick={handleClick}>Submit</div>

This element:

• Cannot be focused with a keyboard

• Does not respond to Enter/Space

• Is invisible to screen readers

Good Example

<button type="button" onClick={handleClick}>Submit</button>

This automatically supports:

• Keyboard interaction

• Focus management

• Screen reader announcements

Custom Component Example (if needed)

<div
  role="button"
  tabIndex={0}
  onClick={handleClick}
  onKeyDown={(e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      handleClick();
    }
  }}
>
  Submit
</div>

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 <button> element, browsers automatically provide keyboard support, focus behavior, and accessibility roles. In contrast, non-semantic elements like <div>require additional attributes and manual handling to achieve the same functionality.

From a readability perspective, semantic HTML makes your code easier to understand and maintain. Developers can quickly identify the structure and intent of a component without relying on class names or external documentation.

Bad Example (Non-semantic)

<div onClick={handleClick}>Submit</div>

Why this is problematic:

• The <div>element has no inherent meaning or role

• It is not focusable by default, so keyboard users can't access it

• It does not respond to keyboard events like Enter or Space unless explicitly coded

• Screen readers do not recognize it as an interactive element

To make this accessible, you would need to add:

role="button"

tabIndex="0"

Keyboard event handlers

Good Example (Semantic)

<button type="button" onClick={handleClick}>Submit</button>

Why this is better:

• The <button> element is inherently interactive

• 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 <button>, <a>, and <form> come with default accessibility behaviors such as focus management and keyboard interaction

It also reduces complexity: you don’t need to manually implement roles, keyboard handlers, or tab navigation

They provide better screen reader support as well. Assistive technologies can correctly interpret the purpose of elements and announce them appropriately

Semantic HTML also improves maintainability and helps other developers quickly understand the intent of your code without reverse-engineering behavior from event handlers

Finally, you'll generally have fewer bugs in your code. Relying on native browser behavior reduces the risk of missing critical accessibility features

Here's another example:

Non-semantic:

<div className="nav">
  <div onClick={goHome}>Home</div>
</div>

Semantic:

<nav>
  <a href="/">Home</a>
</nav>

Here, <nav> clearly defines a navigation region, and <a> provides built-in link behavior, including keyboard navigation and proper screen reader announcements.

Structuring a Page with Semantic Elements

When building a React application, structuring your layout with semantic HTML elements helps define clear regions of your interface. Instead of relying on generic containers like <div>, semantic elements communicate the purpose of each section to both developers and assistive technologies.

In the example below, we're creating a basic page layout using commonly used semantic elements such as <header>, <nav>, <main>, <section>, and <footer>. Each of these elements represents a specific part of the UI and contributes to better accessibility and maintainability.

function Layout() {
  return (
    <>
      {/* Skip link for keyboard and screen reader users */}
      <a href="#main-content" className="skip-link">
        Skip to main content
      </a>

      <header>
        <h1>My App</h1>
      </header>

      <nav>
        <ul>
          <li><a href="/">Home</a></li>
        </ul>
      </nav>

      <main id="main-content">
        <section>
          <h2>Dashboard</h2>
        </section>
      </main>

      <footer>
        <p>© 2026</p>
      </footer>
    </>
  );
}

Each element in this layout has a specific role:

• The skip link allows screen reader users to skip to the main content

• <header>: Represents introductory content or branding

• <nav>: Contains navigation links

• <main>: Holds the primary content of the page

• <section>: Groups related content within the page

• <footer>: Contains closing or supplementary information

Using these elements correctly ensures your UI is both logically structured and accessible by default.

Why this structure is important:

Properly structuring a page like this brings with it many benefits.

For example, it gives you Improved screen reader navigation. This is because semantic elements allow screen readers to identify different regions of the page (for example, navigation, main content, footer). Users can quickly jump between these sections instead of reading the page linearly

It also gives you better document structure. Elements like <main> and <section> define a logical hierarchy, making content easier to parse for both browsers and assistive technologies

Search engines also use semantic structure to better understand page content and prioritize important sections, resulting in better SEO.

It also makes your code more readable, so other devs can immediately understand the layout and purpose of each section without relying on class names or comments

And it provides built-in accessibility landmarks using elements like <nav> and <main>, allowing assistive technologies to provide shortcuts for users.

Building Responsive Layouts

Responsive layouts ensure that your UI adapts smoothly across different screen sizes, from mobile devices to large desktop displays. Instead of building separate layouts for each device, modern CSS techniques like Flexbox, Grid, and media queries allow you to create flexible, fluid designs.

In this section, we’ll look at how layout behavior changes based on screen size, starting with a mobile-first approach and progressively enhancing the layout for larger screens.

Using CSS Flexbox:

.container {
  display: flex;
  flex-direction: column;
}

@media (min-width: 768px) {
  .container {
    flex-direction: row;
  }
}

On smaller screens (mobile), elements are stacked vertically using flex-direction: column, making content easier to read and scroll.

On larger screens (768px and above), the layout switches to a horizontal row, utilizing available screen space more efficiently.

Why this helps:

• Ensures content is readable on small devices without horizontal scrolling

• Improves layout efficiency on larger screens

• Supports a mobile-first design strategy by defining the default layout for smaller screens first and enhancing it progressively

Using CSS Grid:

.grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 16px;
}

@media (min-width: 768px) {
  .grid {
    grid-template-columns: repeat(3, 1fr);
  }
}

On mobile devices, content is displayed in a single-column layout (1fr), ensuring each item takes full width.

On larger screens, the layout shifts to three equal columns using repeat(3, 1fr), creating a grid structure.

Why this helps:

• Provides a clean and consistent way to manage complex layouts

• Makes it easy to scale from simple to multi-column designs

• Improves visual balance and spacing across different screen sizes

React Example:

function CardGrid() {
  return (
    <div className="grid">
      <div className="card">Item 1</div>
      <div className="card">Item 2</div>
      <div className="card">Item 3</div>
    </div>
  );
}

The React component uses the .grid class to apply responsive Grid behavior. Each card automatically adjusts its position based on screen size.

Why this is effective:

• Separates structure (React JSX) from layout (CSS)

• Allows you to reuse the same component across different screen sizes without modification

• Ensures consistent responsiveness across your application with minimal code

By combining Flexbox for one-dimensional layouts and Grid for two-dimensional layouts, you can build highly adaptable interfaces that respond efficiently to different devices and screen sizes.

Accessibility with ARIA

ARIA (Accessible Rich Internet Applications) is a set of attributes that enhance the accessibility of web content, especially when building custom UI components that cannot be fully implemented using native HTML elements.

ARIA works by providing additional semantic information to assistive technologies such as screen readers. It does this through:

• Roles, which define what an element is (for example, button, dialog, menu)

• States and properties, which describe the current condition or behavior of an element (for example, expanded, hidden, live updates)

For example, when you create a custom dropdown using <div> elements, browsers don't inherently understand its purpose. By applying ARIA roles and attributes, you can communicate that this structure behaves like a menu and ensure it is interpreted correctly.

Just make sure you use ARIA carefully. Incorrect or unnecessary usage can reduce accessibility. Here's a key rule to follow: use native HTML first. Only use ARIA when necessary.

ARIA is especially useful for:

• Custom UI components (modals, tabs, dropdowns)

• Dynamic content updates

• Complex interactions not covered by standard HTML

Something to note before we get into the examples here: real-world accessibility is complex. For production apps, you should typically prefer well-tested libraries like react-aria, Radix UI, or Headless UI. These examples are primarily for educational purposes and aren't production-ready.

Example: Accessible Modal

function Modal({ isOpen, onClose }) {
  const dialogRef = React.useRef();

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

  if (!isOpen) return null;

  return (
    <div
      role="dialog"
      aria-modal="true"
      aria-labelledby="modal-title"
      tabIndex={-1}
      ref={dialogRef}
      onKeyDown={(e) => {
        if (e.key === 'Escape') onClose();
      }}
    >
      <h2 id="modal-title">Modal Title</h2>
      <button type="button" onClick={onClose}>Close</button>
    </div>
  );
}

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 (
    <div>
      <button
        type="button"
        aria-expanded={isOpen}
        aria-controls="dropdown-menu"
        onClick={toggle}
      >
        Menu
      </button>

      {isOpen && (
        <ul id="dropdown-menu">
          <li>
            <button type="button" onClick={() => console.log('Item 1')}>
              Item 1
            </button>
          </li>
          <li>
            <button type="button" onClick={() => console.log('Item 2')}>
              Item 2
            </button>
          </li>
        </ul>
      )}
    </div>
  );
}

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 <button> element acts as the trigger and is fully keyboard accessible

• The <ul> and <li> elements provide a natural list structure

• Using <a> 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 <button>, as they already support keyboard interaction by default.

For example, this is all you need:

<button type="button" onClick={handleClick}>Submit</button>

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 <button>. These elements already provide built-in keyboard support and accessibility features.

For example:

<button type="button" onClick={handleClick}>Submit</button>

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 (
    <div role="dialog">
      <button type="button" ref={ref}>Close</button>
    </div>
  );
}

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 (
    <div role="dialog" ref={modalRef} tabIndex={-1}>
      <button type="button" onClick={onClose}>Close</button>
    </div>
  );
}

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();
}, []);
<input ref={ref} placeholder="Name" />

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 (
    <div
      role="dialog"
      aria-modal="true"
      aria-labelledby="modal-title"
      tabIndex={-1}
      ref={dialogRef}
    >
      <h2 id="modal-title">Modal Title</h2>
      <button type="button" onClick={onClose}>Close</button>
      <input type="text" placeholder="Name" />
    </div>
  );
}

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:

<div
  onKeyDown={(e) => {
    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:

<input type="text" placeholder="Name" />

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:

<label htmlFor="name">Name</label>
<input id="name" type="text" />

Why this is better:

• The <label> 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:

<label htmlFor="name">Name</label>
<input
  id="name"
  type="text"
  aria-describedby="name-error"
  aria-invalid="true"
/>

<p id="name-error" role="alert">
  Name is required
</p>

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:

<img src="image.jpg" alt="Description" loading="lazy" />

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:

<img src="image-small.jpg"
     srcset="image-small.jpg 480w,
             image-medium.jpg 1024w,
             image-large.jpg 1920w"
     sizes="(max-width: 600px) 480px,
            (max-width: 1200px) 1024px,
            1920px"
     alt="Description">

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 (
    <article className="card">
      <h3>{title}</h3>
      <p>{description}</p>
      <button type="button" onClick={onAction}>
        View Details
      </button>
    </article>
  );
}

Why This Works

• <article> provides semantic meaning for standalone content

• <h3> establishes a proper heading hierarchy

• <button> ensures built-in keyboard and accessibility support

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

<button type="button" onClick={onAction}>
  View Details
</button>

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 (
    <div className="grid">
      <ProductCard
        title="Product 1"
        description="Accessible and responsive"
        onAction={() => alert('Clicked')}
      />
    </div>
  );
}

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.

Each certification is filled with hundreds of hours worth of interactive lessons, workshops, labs, and quizzes.

How Does the New RWD Certification Work?

The Responsive Web Design certification will teach you core concepts including semantic HTML, working with forms, the importance of accessibility, CSS Flexbox, responsive design, CSS Grid, and more.

The certification is broken down into several modules that include lessons, workshops, labs, review pages and quizzes to ensure that you truly understand the material before moving onto the next module.

The lessons are your first exposure to new concepts. They provide crucial theory and context for how things work in the software development industry.

These lessons include our new interactive editor so you can see previews of the code. You can also play around with the examples for deeper understanding and comprehension.

At the end of each lesson, there will be three comprehension check questions to test your understanding of the material from the lesson.

After these lessons, you’ll head over to the workshops. These workshops are guided step-based projects that provide you with an opportunity to practice what you have learned in the lessons.

After the workshops, you’ll complete a lab which will help you review what you have learned so far. This will give you the chance to start building projects on your own, which is a crucial skill for a developer. You’ll be presented with a list of user stories and will need to pass the tests to complete the lab.

At the end of each module, there is a review page containing a list of all of the concepts covered. You can use these review pages to help you study for the quizzes.

The last portion of the module is the quiz. This is a 20 question multiple choice quiz designed to test your understanding from the material covered in the module. You’ll need to get 18 out of 20 correct to pass.

Throughout the certification, there will be five certification projects you’ll need to complete in order to qualify for the exam.

Once you’ve completed all 5 certification projects, you’ll be able to take the 50 question exam using our new open source exam environment. The freeCodeCamp community designed this exam environment tool with two goals: respecting your privacy while also making it harder for people to cheat.

Once you download the app to your laptop or desktop, you can take the exam.

Frequently Asked Questions

Is all of this really free?

Yes. freeCodeCamp has always been free, and we’ve now offered free verified certifications for more than a decade. These exams are just the latest expansion to our community’s free learning resources.

What prevents people from just cheating on the exams?

Our goal is to strike a balance between preventing cheating and respecting people's right to privacy.

We've implemented a number of reliable, yet non-invasive, measures to help prevent people from cheating on freeCodeCamp's exams:

1. For each exam, we have a massive bank of questions and potential answers to those questions. Each time a person attempts an exam, they'll see only a small, randomized sampling of these questions.

2. We only allow people to attempt an exam one time per week. This reduces their ability to "brute force" the exam.

3. We have security in place to validate exam submissions and prevent man-in-the-middle attacks or manipulation of the exam environment.

4. We manually review each passing exam for evidence of cheating. Our exam environment produces tons of metrics for us to draw from.

We take cheating, and any form of academic dishonesty, seriously. We will act decisively.

This said, no one's exam results will be thrown out without human review, and no one's account will be banned without warning based on a single suspicious exam result.

Are these exams “open book” or “closed book”?

All of freeCodeCamp’s exams are “closed book”, meaning you must rely only on your mind and not outside resources.

Of course, in the real world you’ll be able to look things up. And in the real world, we encourage you to do so.

But that is not what these exams are evaluating. These exams are instead designed to test your memory of details and your comprehension of concepts.

So when taking these exams, do not use outside assistance in the form of books, notes, AI tools, or other people. Use of any of these will be considered academic dishonesty.

Do you record my webcam, microphone, or require me to upload a photo of my personal ID?

No. We considered adding these as additional test-taking security measures. But we have less privacy-invading methods of detecting most forms of academic dishonesty.

If the environment is open source, doesn't that make it less secure?

"Given enough eyeballs, all bugs are shallow." – Linus’s Law, formulated by Eric S. Raymond in his book The Cathedral and the Bazaar

Open source software projects are often more secure than their closed source equivalents. This is because a lot more people are scrutinizing the code. And a lot more people can potentially help identify bugs and other deficiencies, then fix them.

We feel confident that open source is the way to go for this exam environment system.

How can I contribute to the Exam Environment codebase?

It's fully open source, and we'd welcome your code contributions. Please read our general contributor onboarding documentation.

Then check out the GitHub repo.

You can help by creating issues to report bugs or request features.

You can also browse open help wanted issues and attempt to open pull requests addressing them.

Are the exam questions themselves open source?

For obvious exam security reasons, the exam question banks themselves are not publicly accessible. :)

These are built and maintained by freeCodeCamp's staff instructional designers.

What happens if I have internet connectivity issues mid-exam?

If you have internet connectivity issues mid exam, the next time you try submit an answer, you’ll be told there are connectivity issues. The system will keep prompting you to retry submitting until the connection succeeds.

What if my computer crashes mid-exam?

If your computer crashes mid exam, you’ll be able to re-open the Exam Environment. Then, if you still have time left for your exam attempt, you’ll be able to continue from where you left off.

Can I take exams in languages other than English?

Not yet. We’re working to add multi-lingual support in the future.

I have completed my exam. Why can't I see my results yet?

All exam attempts are reviewed by freeCodeCamp staff before we release the results. We do this to ensure the integrity of the exam process and to prevent cheating. Once your attempt has been reviewed, you'll be notified of your results the next time you log in to freeCodeCamp.org.

I am Deaf or hard of hearing. Can I still take the exams?

Yes! While some exams may include audio components, we do make written transcripts available for reading.

I am blind or have limited vision, and use a screen reader. Can I still take the exams?

We’re working on it. Our curriculum is fully screen reader accessible. We're still refining our screen reader usability for the Exam Environment app. This is a high priority for us.

I use a keyboard instead of a mouse. Can I navigate the exams using just a keyboard?

This is a high priority for us. We hope to add keyboard navigation to the Exam Environment app soon.

Are exams timed?

Yes, exams are timed. We err on the side of giving plenty of time to take the exam, to account for people who are non-native English speakers, or who have ADHD and other learning differences that can make timed exams more challenging.

If you have a condition that usually qualifies you for extra time on standardized exams, please email support@freecodecamp.org. We’ll review your request and see whether we can find a reasonable solution.

What happens if I fail the exam? Can I retake it?

Yes. You get one exam attempt per week. After you attempt an exam, there is a one-week (exactly 168 hour) “cool-down” period where you cannot take any freeCodeCamp exams. This is to encourage you to study and to pace yourself.

There is no limit to the number of times you can take an exam. So if you fail, study more, practice your skills more, then try again the following week.

Do I need to redo the projects if I fail the exam?

No. Once you’ve submitted a certification project, you do not need to ever submit it again.

You can re-do projects for practice, but we recommend that you instead build some of our many practice projects in freeCodeCamp’s developer interview job search section.

What happens if I already have the old Legacy Responsive Web Design certification? Should I claim the new one?

The new certification has more theory and practice as well as an exam. So if you’re looking to brush up on your skills, then you can go through the new version of this certification.

What will happen to my existing coursework progress on the Full Stack Certification? Does it transfer over to the Responsive Web Design course?

If you’ve already started the Certified Full Stack Developer Curriculum, all of your previously completed work should already be saved there.

To be clear, we’ve copied over all of the coursework from the full stack certification to this newer certification.

Can I still continue with the current Full Stack Developer Certification and just not do the new certification?

We’ve moved the coursework for the Full Stack Developer Certification over and broken it up into smaller certifications. Currently there are seven courses available for you to go through. Here is the complete list:

• Responsive Web Design Certification

• JavaScript Certification

• Frontend Libraries Certification

• Python Certification

• Relational Databases Certification

• Backend JavaScript Certification

• Certified Full Stack Developer Certification

The Certified Full Stack Developer Certification button will remain on the learn page for a short time to give people the opportunity to switch over to the new certifications. Over the next few months, though, this option will disappear.

Will my legacy certifications become invalid?

No. Once you claim a certification, it’s yours to keep.

Also note that we previously announced that freeCodeCamp certifications would have an expiration date and require recertification. We don’t plan to implement this anytime soon. And if we do decide to, we will give everyone at least a year’s notice.

Will the exam be available to take on my phone?

At this time, no. You’ll need to use a laptop or desktop to download the exam environment and take the exam. We hope to eventually offer these certification exams on iPhone and Android.

I have a disability or health condition that is not covered here. How can I request accommodations?

If you need specific accommodations for the exam (for example extra time, breaks, or alternative formats), please email support@freecodecamp.org. We’ll review your request and see whether we can find a reasonable solution.

Anything else?

Good luck working through freeCodeCamp’s coursework, building projects, and preparing for these exams.

Happy coding!

Before now, developers used tags like <br> or <span> to manually adjust word spacing. But what happens in cases where you also need to consider the responsiveness of the website? Well, the new text-wrap: balance property in CSS can now automatically calculate and divide the lines in such a way that every word looks organized and even. Like this:

In this article, you’ll learn how the text-wrap property works and how to use it in your code. You’ll also see a few examples along the way.

Without wasting time, let's get right into it.

Table of Contents

• Understanding the Problems

• Introducing text-wrap

  • What is text-wrap?

  • Basic Syntax of text-wrap

• text-wrap vs. max-width : When to Use Each

  • When to Use max-width vs text-wrap

  • Browser Support and Considerations

• Practical Implementation: Step-by-Step Guide

• Conclusion

Understanding the Problems

Apart from making words harder to read when your text is unevenly displayed, there are other issues uneven or poorly displayed text can cause on your website as a whole. Some of these are:

• Responsive Design: We wouldn't have any issues if we could manually design for every screen size and carefully place and space the lines of our text exactly as we wanted users to read them. Unfortunately, we can't do this, which is why making designs responsive is always crucial. When text adjusts from one screen size to another, lines break, and what looks good on a desktop may look terrible on a tablet view.

• Headings and Short Paragraphs: Since paragraphs and small blocks of text have many words, there is a high probability of words ending in a very unbalanced way. Often, we see a heading line ending with just one word, forming an awkward shape in the overall design.

• Dynamic Content: If your website contains dynamic content (such as cards of various sizes, product descriptions, or blog posts), having no text-wrap might make your layout break or appear unpredictable.

Introducing text-wrap

In the last section, we looked at the problems attributed to uneven text distribution. In this section, you’ll see how text-wrap is a game changer in how you organize your text.

Before text-wrap, developers relied heavily on max-width, text-align, or <br> to control text lines. The new text-wrap CSS property was created to help break text naturally across lines without making it look out of place, preventing the need for trial and error in checking if text fits.

What is text-wrap?

text-wrap is a CSS property that can help you adjust and space text automatically, break lines evenly without using the rigid <br> tag, and not have to rely on text-align, which didn't work on all screen sizes.

With text-wrap, your headings and paragraphs are sure to look good. Instead of having some lines that look longer than others, text-wrap neatly arranges everything to appear visually appealing.

Basic Syntax of text-wrap

There are two major ways to apply text-wrap to your text. These values are:

text-wrap: balance: (The Smart Heading Balancer)

This is the smart way of telling the browser to adjust the text evenly, regardless of the screen size.

Code snippet:

h1 {
  text-wrap: balance;
}

In this code, the heading text lines will split naturally without any weird short lines.

text-wrap: pretty; (The Smart Paragraph Balancer)

Just as text-wrap: balance works best for headings, text-wrap: pretty is the best for styling long paragraphs.

Code snippet:

p{
  text-wrap: pretty;
}

The p in this code will make sure the paragraphs maintain natural readability.

Other values include:

text-wrap vs. max-width : When to Use Each

max-width was always the go-to option for developers in the past. While this method works in most cases, it won’t stop uneven text distribution. Let's compare it with the new text-wrap CSS property so you can know when to use each one.

Using max-width:

h1 {
  max-width: 400px;
}

The max-width here forces the heading not to exceed a 400px width. This can be good for controlling short body paragraphs but can cause unevenness for headings when dealing with multiple screen sizes.

Using text-wrap:

h1 {
  text-wrap: balance;
}

Here, the browser dynamically breaks the heading text in a balanced way, preventing any weird-looking single lines.

When to Use max-width vs text-wrap

Use text-wrap: balance when you want a more natural text read without any weird line breaks.

Use max-width when you need to control the text width and don't necessarily care how the lines break.

Use both if you want a more natural read within a confined width limit.

h1 {
  max-width: 500px;
  text-wrap: balance;
}

This ensures the heading stays within a 500px limit while maintaining an even text distribution.

Browser Support and Considerations

Currently, Chrome and Edge are the only main browsers that support the new text-wrap property. If you are building a project that should work on browsers like Safari and Firefox, you will need to use traditional text formatting methods like text-align, <br>, or max-width instead.

Fallback snippet:

@supports (text-wrap: balance) {
  h1 {
    text-wrap: balance;
  }
}

The @support is a pro tip to apply this style to only supported browsers.

Practical Implementation: Step-by-Step Guide

Now that you’ve seen how important text-wrap can be and how to use it, let’s put that knowledge into practise and see real examples, compare the before and after screens of using it (and not), and check how it reacts in responsive designs as well.

1. Applying text-wrap: balance to Headings

In this section, we will see how the heading lines in the topic "How to Use CSS Text Balance: A Simple Trick for Smoother, Cleaner Designs" will break across different sizes and how it looks when text-wrap: balance is applied.

Without text-wrap: balance:

HTML

<h1 class="title">How to Use CSS Text Balance: A Simple Trick for Smoother, Cleaner Designs</h1>

CSS

.title {
  font-size: 2.5rem;
  font-weight: bold;
}

Without any special application to the headings, it will just adjust freely.

Result:

With text-wrap: balance:

CSS

.title {
  font-size: 2.5rem;
  font-weight: bold;
  text-wrap: balance;
}

Now, the browser automatically adjusts the line breaks to ensure a more even distribution.

Result:

2. Using text-wrap: pretty on Short Paragraphs

You’ve now seen how text-wrap: balance handles headings, so lets also take a look at how it breaks the lines evenly in your text paragraphs. As I mentioned above, the value pretty is mostly used for paragraphs or short block of words. Here’s how it works and appears on a block of text.

Without text-wrap: pretty:

HTML

<p class="subText"> Do you know that inconsistent text layout can ruin the look of your website design? Maybe a heading has an extra word that takes up another line or in a paragraph some lines are longer than others whereby leaving the whole thing looking messed up and hard to read.</p>

CSS

.subText {
  font-size: 1.2rem;
  line-height: 1.5;
}

In this code, text adjustment will behave normally without any smart contraints.

Result:

With text-wrap: pretty:

CSS

.subText {
  font-size: 1.2rem;
  line-height: 1.5;
  text-wrap: pretty;
}

The code above makes the line breaks evenly in a way that it will be easier for someone to read through.

Result:

How text-wrap Works in Responsive Design

When you use text-wrap on your text, you need not to worry how it is going to appear on various screen sizes. The below video shows you what I mean by that:

Using Media Queries for Extra Control

Combine media-queries and text-wrap to have a great special kind of control on how your text appears on various screens.

h1 {
  font-size: 2.5rem;
  text-wrap: balance;
}

/* On smaller screens, reduce font size and apply text-balancing */
@media (max-width: 600px) {
  h1 {
    font-size: 2rem;
    text-wrap: balance;
  }
}

This code ensures your heading text adapts and remains clean across multiple device sizes.

Conclusion

How text displays is something every good developer should pay attention to. It plays a big role in user experience. By using text-wrap, you can ensure that your website layouts don't look messy or difficult to read.

One of the best things about using text-wrap in your text formatting is that it just works every time. You don’t need to bother with <br> tags, tweak max-width, or fight with text alignment.

Even though it's not yet supported by all browsers, adding it to your next project will future-proof your design so it’s always intact and good-looking.

We just published a course on the freeCodeCamp.org Spanish YouTube channel that will teach you Responsive Web Development by building a website step by step. You will use the core concepts that you need to understand in order to master responsive web development. By the end of the course, you will be able to design and implement responsive websites using HTML and CSS.

If you have Spanish-speaking friends, you are welcome to share the Spanish version of this article with them.

This course was created by David Choi. David is a Software Developer who loves coding and sharing his knowledge with everyone who wants to dive into the world of programming and computer science.

David will teach you how to create and implement modern and responsive web designs step by step with HTML and CSS (without frameworks or libraries).

If your goal is to design and create modern websites, you definitely need to learn how to make them responsive. Before you start learning responsive web development with David's course, let's have a quick introduction.

What is Responsive Web Development?

A responsive website is a website that adapts its layout and content to fit the size of the screen. It should look and work correctly on desktops, laptops, tablets, smartphones, and other devices.

Responsive web development is the approach used by developers to create these websites that adapt to devices of different sizes. This results in a much better user experience because the user will have access to the content in a layout that has been specifically adapted to their device. Search engines also reward sites that offer a good user experience for all devices.

You can develop responsive websites with HTML and CSS. This is where CSS Flexbox comes to the rescue. You will practice your CSS Flexbox skills during the course. Let's see what it is all about.

What is Flexbox?

Flexbox is a CSS layout model for arranging elements in a single dimension. With Flexbox, you can place elements horizontally or vertically, distribute space evenly to resize the layout based on screen size, and even control the order of the elements.

💡 Tip: If you need to refresh your HTML, CSS, and Flexbox skills, you can take courses on these topics on our Spanish YouTube channel before diving into the project.

• Aprende HTML y CSS - Curso Desde Cero

• Aprende CSS Flexbox - Curso desde Cero

Responsive Website Project in Spanish

During the course, you will:

• Analyze the website design and translate it into HTML.

• Prepare your development environment.

• Install Visual Studio Code.

• Create the structure of the website in HTML.

• Define and assign CSS styles for the mobile version.

• Define and assign CSS styles for the desktop version.

You will combine basic CSS with Flexbox to assign styles that adapt to the current size of the screen.

Here we have some course screenshots to give you an idea of the awesome project that you will be building with David:

If you are ready to start building this project, check out the course in Spanish on the freeCodeCamp.org Spanish YouTube channel:

✍️ Course created by David Choi.

• YouTube: @deivchoi

• GitHub: @choidavid4