A practical, in-depth walkthrough of building fast, accessible UI components with ARIA, semantic HTML, and performance patterns.

An interface that looks good but cannot be used with a keyboard, a screen reader or a slow phone is unfinished work. This tutorial walks step by step through making Bootstrap-based components accessible (correct semantics and ARIA roles) and fast (good Core Web Vitals). Each step includes what to change, why it matters, and how to verify it.

Code editor open with HTML markup being refactored — Figure 1 — Most accessibility fixes are markup changes, not new code.

The mental model

HTML semantics → accessibility tree → screen reader / keyboard ↑ ↑ native element ARIA (only when no native element exists)

The single most important rule: the first rule of ARIA is not to use ARIA. A native <button> already announces its role, is focusable, and fires on Enter and Space. A <div role="button"> needs a tabindex, two key handlers and a role — three chances to get it wrong.

Step 1 — Fix the document skeleton

Start every page with landmarks so screen-reader users can jump between regions.

<header> … site header, contains <nav> … </header>
<main>   … the unique page content, exactly one per page … </main>
<footer> … site footer … </footer>

Set <html lang="en"> (or bn) so pronunciation is correct.
Use exactly one <h1>, then never skip heading levels.
Add a skip link as the first focusable element: <a class="visually-hidden-focusable" href="#main">Skip to content</a>.

Step 2 — Give every control an accessible name

Icon-only buttons are the most common failure in copy-pasted components.

<button class="btn btn-light" aria-label="Close menu">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

Decorative images: alt="". Meaningful images: describe the content, not the file.
Inline SVG icons: aria-hidden="true" plus a label on the parent control.
Form fields: a real <label for="id">; placeholders are not labels.

Step 3 — Wire the ARIA state that Bootstrap expects

Bootstrap’s JavaScript toggles some attributes for you, but you must supply the initial state. The patterns you will use most:

Collapse / navbar toggler

<button data-bs-toggle="collapse" data-bs-target="#nav"
        aria-controls="nav" aria-expanded="false"
        aria-label="Toggle navigation">

Modal

<div class="modal fade" id="signup" tabindex="-1"
     aria-labelledby="signupTitle" aria-hidden="true">
  <h2 class="modal-title" id="signupTitle">Create an account</h2>

Tabs

<ul class="nav nav-tabs" role="tablist">
  <li role="presentation">
    <button role="tab" aria-selected="true" aria-controls="pane-1">Overview</button>

Live regions

Toasts, validation errors and “copied!” confirmations must live in aria-live="polite" containers, otherwise a screen reader never announces them.

Step 4 — Make keyboard navigation complete

Unplug the mouse and Tab through the whole page.
Every interactive element must be reachable and must show a visible focus ring. Never write outline:none without a replacement.
Escape must close modals, offcanvas panels and dropdowns.
Focus must be trapped inside an open modal and returned to the trigger on close (Bootstrap does this for you — do not disable it).

Step 5 — Check colour and motion

Body text needs a contrast ratio of at least 4.5:1; large text 3:1.
Never use colour alone to signal state — pair red with an icon and text.
Respect reduced motion:

@media (prefers-reduced-motion: reduce){
  *{animation-duration:.01ms !important; transition-duration:.01ms !important}
}

Analytics and performance metrics displayed on a dashboard — Figure 2 — Accessibility and performance are measured, not guessed.

Part two: UI performance

Google grades three metrics. Learn what each one punishes:

LCP largest contentful paint → slow hero image / render-blocking CSS INP interaction to next paint → heavy JavaScript on the main thread CLS cumulative layout shift → images and ads without reserved space

Step 6 — Fix LCP first

Serve the hero image in WebP or AVIF at the size it is actually displayed.
Add fetchpriority="high" to the hero image and loading="lazy" to everything below the fold.
Preconnect to font and image origins; load Google Fonts non-blocking and use font-display: swap.
Ship only the CSS the page needs — Bootstrap’s full bundle is fine over HTTP/2, but do not stack three UI frameworks.

Step 7 — Protect INP

Load scripts with defer; never block parsing.
Split heavy widgets (editors, charts, carousels) and lazy-load them when they scroll into view.
Debounce input handlers and avoid layout thrashing — batch DOM reads, then writes.
Animate only transform and opacity; they run on the compositor.

Step 8 — Eliminate CLS

Always set width and height (or aspect-ratio) on images, iframes and ad slots.
Reserve a min-height for any content that loads asynchronously.
Never insert banners above existing content after paint.

Step 9 — Verify with real tools

Lighthouse (Chrome DevTools) for a scored baseline.
axe DevTools or the built-in Accessibility pane for the ARIA tree.
Keyboard only pass — the fastest manual test there is.
NVDA (Windows) or VoiceOver (macOS/iOS) on your most important flow.

Automated tools catch roughly a third of real issues. The keyboard and screen-reader passes catch the rest.

Pre-launch checklist

One <h1>, logical heading order, landmarks present
Every control has a name; every image has correct alt text
Visible focus everywhere; Escape closes overlays
Contrast ≥ 4.5:1; reduced motion respected
Hero image optimised; below-fold images lazy; no layout shift

Every component in the CodeShikhi library is written against this checklist, so you can start from an accessible baseline instead of retrofitting one.

How to Optimize Modern Web Components for Accessibility (ARIA Roles) and UI Performance