Accessibility in Bootstrap Components

Bootstrap's JavaScript components include a meaningful amount of built-in accessibility behavior, but "built on Bootstrap" is not the same as "accessible" — most of the accessibility work still depends on markup choices you make yourself.

What Bootstrap gives you automatically

A handful of behaviors come from Bootstrap's JS with no extra effort on your part, as long as you use the documented markup:

• Modals trap keyboard focus inside the dialog while open, and restore it to the triggering element on close (covered in the modals lesson).
• Dropdowns and modals close on Escape, matching the keyboard behavior users expect from any dialog or menu.
• Carousel controls are real <button> elements, so they're keyboard-focusable and get default button semantics for free.
• Toggle buttons (data-bs-toggle="button") update aria-pressed automatically as their state changes.

These are genuine wins — building correct focus trapping by hand is notoriously easy to get subtly wrong, and getting it from a well-tested library instead is one of the best arguments for using Bootstrap's JS components rather than styling your own from scratch.

What's still on you

None of that removes the need for correct markup around the component. A few of the most common gaps:

Icon-only buttons need an accessible name. A close button styled with .btn-close has no visible text — without aria-label, a screen reader announces it as an unlabeled button:

<!-- Missing accessible name -->
<button type="button" class="btn-close" data-bs-dismiss="modal"></button>

<!-- Correct -->
<button type="button" class="btn-close" data-bs-dismiss="modal" aria-label="Close"></button>

Images inside carousels and cards still need real alt text. Bootstrap has no way to know what a carousel slide depicts — it will happily render a slideshow of <img> tags with no alt attribute at all, silently skipping any accessible description.

Color alone shouldn't carry meaning. .text-danger on a form error is a helpful visual cue, but a fully colorblind-safe form pairs it with an icon or explicit text (.invalid-feedback messages, covered in the form validation lesson) rather than relying on red text alone.

aria-current on navbar links. Bootstrap styles an .active navbar link visually, but doesn't add aria-current="page" for you — that's a manual addition that tells screen reader users which link represents the current page:

<a class="nav-link active" aria-current="page" href="#">Home</a>

Testing your own Bootstrap pages

The same habits from general HTML accessibility apply directly here:

• Tab through interactive components (dropdowns, modals, carousels) using only the keyboard, and confirm focus moves somewhere sensible.
• Check that every icon-only button, close control, and toggle has an aria-label or visible text.
• Run an automated checker like axe or Lighthouse — it catches missing alt attributes and contrast issues, though it can't catch everything (like whether tab order is logical, not just present).

Bootstrap gives you a strong accessible foundation for its components' behavior. Whether the content inside them is accessible is still entirely up to how you write the markup.