Accessibility

Prev Next

Bootstrap 4 bakes in a real, useful amount of accessibility support — but it is not a substitute for thinking about accessibility yourself. Some things (focus outlines, screen-reader-only text, ARIA wiring on interactive components) come for free once you use the classes correctly. Other things (color contrast, meaningful alt text, a sane heading order) are entirely on you, no matter which framework you're using. Let's audit TrailMap's navbar against both lists.

What Bootstrap 4 Gives You

Feature	What it does
Visible focus states	Buttons, links, and form controls get a visible outline/box-shadow on keyboard focus by default — don't remove it with a stray `outline:none`
`.sr-only`	Visually hides text while keeping it in the accessibility tree, for screen-reader-only context (e.g. "(current)" after an active nav link)
Baked-in ARIA on components	The modal, collapse, and similar interactive components' documented markup already includes attributes like `aria-hidden`, `aria-expanded`, and `aria-labelledby` when you use the markup as documented
Semantic form markup	`<label for="...">` paired with a matching input `id` is part of every documented form example

Note: every one of these only helps if you copy the component's complete documented markup. Strip out the aria-* attributes from a modal example to "clean it up," and you've thrown away the accessibility Bootstrap was giving you for free.

What's Still Your Responsibility

Concern	Why Bootstrap can't fix it for you
Color contrast	You choose the actual colors (including any Sass `$variable` overrides) — Bootstrap can't know if your trail-green-on-white passes WCAG contrast
Meaningful `alt` text	Bootstrap has no idea what a given `<img>` shows; a trail photo needs a real description, not `alt=""` or the filename
Heading order	`.h1`–`.h6` utility classes just apply font sizing — they don't enforce that your actual `<h1>`–`<h6>` tags nest in a logical order
Icon-only controls	An icon-only button (see the previous lesson's heart/save button) needs an `aria-label` you write yourself — Bootstrap doesn't add one

Worked Audit: TrailMap's Navbar

Revisiting the navbar markup from the Navbar lesson with an accessibility eye:

<button class="navbar-toggler" type="button"
        data-toggle="collapse" data-target="#trailNav"
        aria-controls="trailNav" aria-expanded="false" aria-label="Toggle navigation">
  <span class="navbar-toggler-icon"></span>
</button>

<a class="nav-link" href="#">Trails <span class="sr-only">(current)</span></a>

Already covered by Bootstrap's documented markup: the toggler ships with aria-controls, aria-expanded, and aria-label — a screen-reader user hears "Toggle navigation" and its current expanded/collapsed state, not silence on an unlabeled icon button.
Already covered: .sr-only announces "(current)" to screen-reader users on the active link without adding visible clutter for sighted users.
Still on you: the brand link's icon (<i class="fa fa-map-o">) is decorative next to visible "TrailMap" text, so it needs no separate label — but if that same icon were ever used alone as the brand link with no visible text, it would need its own aria-label="TrailMap home".
Still on you: whether .navbar-dark.bg-dark or .navbar-light.bg-light is the right choice depends on whether that exact text color against that exact background actually passes contrast — Bootstrap ships both options but doesn't check which one you picked correctly.

Next up, learn what Bootstrap 4's jQuery/Popper.js dependency actually costs, and how to trim it, in Performance.

Prev Next