Page Containers

page - width contols

container-xl
container-lg
container-md
container-sm

Page Containers sm, md, lg, xl

Responsive Width Control

Using clamp() + vw + max-width (px) creates adaptive containers that flexibly scale across viewports but never grow too wide.

Matches modern best practices for responsive layouts (good for desktops, tablets, and phones).

Flexible Baseline for Containers

.container-xl uses 100% width - True full-viewport sections (hero banners, background images, etc.).

.container-lg, .container-md, .container-sm progressively shrink for content width comfort.

The container widths are chosen to maintain optimal line length for readability, generally 60–75 characters per line - while also accommodating responsive grid alignment. This helps support WCAG 1.4.8 (Visual Presentation) and 1.4.10 (Reflow).

All container widths respect `width: 100%` on small viewports and scale fluidly with `clamp()`, which allows text and layouts to adapt when zoomed or when the browser width is resized supporting WCAG 1.4.10 (Reflow).

In rare cases where strict layout alignment is required, a `.container-fixed` utility can be used to lock containers to a specific `max-width`. Use only when responsive scaling is not desired, such as fixed headers or comparison tables.

Future-Proof: If using dvw (Dynamic Viewport Units) Including dvw after vw

dvw accounts for browser chrome (e.g., mobile address bars) shrinking the visible area.

Helps prevent unexpected overflow issues especially on iOS Safari and Android Chrome.

Responsive Behavior Beyond Breakpoints

Definition: Accessible responsive design must remain readable, operable, and understandable across all viewport sizes — including in-between widths, zoomed views, and user-modified text and spacing — not just at predefined breakpoints.

Accessibility Requirement: WCAG focuses on functional resilience rather than visual perfection. Content must reflow without loss of information or functionality, text must resize without breaking layout, and interactive elements must remain usable regardless of screen size or zoom level. Designs that only work cleanly at exact breakpoints may fail accessibility requirements if content overlaps, clips, forces horizontal scrolling, or hides controls at intermediate sizes.

Best Practice: Favor fluid, content-driven layouts over breakpoint-only logic. Use flexible units (%, em, rem, clamp()), intrinsic sizing, and adaptable spacing so layouts respond continuously as the viewport changes. Avoid fixed heights, rigid widths, and breakpoint-locked assumptions that break under zoom, split-screen, or custom user settings.

Design System Guidance: Components should be tested and validated at a wide range of viewport sizes, including non-breakpoint widths and high zoom levels. Minor visual imperfection between breakpoints is acceptable; loss of readability, blocked interaction, clipped content, or broken navigation is not.

This approach aligns with WCAG requirements for reflow, text resizing, and operability, and supports users who rely on zoom, larger text, custom spacing, alternative input methods, or non-standard window sizes.

Fluid Responsiveness (Not Just Breakpoints)

Expectation: Layouts must remain usable and readable across the full range of viewport widths, including intermediate sizes between breakpoints, browser zoom states, split-screen layouts, and user-scaled text. Responsive behavior is evaluated continuously, not only at predefined screen widths.

Accessibility Impact: Interfaces that rely solely on breakpoint snapping may appear correct at specific sizes but can become unusable between them. Loss of content, clipped text, overlapping elements, hidden controls, or forced horizontal scrolling at any width introduces accessibility risk.

Implementation Guidance: Use layout techniques that respond to content and available space rather than device assumptions. Prefer flexible containers, intrinsic sizing, and proportional spacing over rigid widths or height-locked components. Breakpoints should refine layout, not rescue it.

Evaluation Standard: A responsive layout is considered accessible when it supports reading, navigation, and interaction at any width without requiring precise viewport alignment or user adjustment. Minor visual imbalance is acceptable; functional degradation is not.

This principle supports WCAG requirements related to reflow, text resizing, orientation, and operability, and ensures compatibility with assistive technologies, zoom usage, and non-standard display environments.

Definition: Accessible responsive design must remain readable, operable, and understandable across all viewport sizes — including in-between widths, zoomed views, and user-modified text and spacing — not just at predefined breakpoints.

Accessibility Requirement: WCAG focuses on functional resilience rather than visual perfection. Content must reflow without loss of information or functionality, text must resize without breaking layout, and interactive elements must remain usable regardless of screen size or zoom level. Designs that only work cleanly at exact breakpoints may fail accessibility requirements if content overlaps, clips, forces horizontal scrolling, or hides controls at intermediate sizes.

Best Practice: Favor fluid, content-driven layouts over breakpoint-only logic. Use flexible units (%, em, rem, clamp()), intrinsic sizing, and adaptable spacing so layouts respond continuously as the viewport changes. Avoid fixed heights, rigid widths, and breakpoint-locked assumptions that break under zoom, split-screen, or custom user settings.

Design System Guidance: Components should be tested and validated at a wide range of viewport sizes, including non-breakpoint widths and high zoom levels. Minor visual imperfection between breakpoints is acceptable; loss of readability, blocked interaction, clipped content, or broken navigation is not.

This approach aligns with WCAG requirements for reflow, text resizing, and operability, and supports users who rely on zoom, larger text, custom spacing, alternative input methods, or non-standard window sizes.

Do

  • Test continuously by dragging the viewport across sizes, not only at breakpoints.
  • Validate reflow at narrow widths and at high zoom without losing content or controls.
  • Use fluid sizing with max-width, percentages, flexible grids, and intrinsic layout.
  • Use scalable typography (e.g., rem and clamp()) and allow line-wrapping.
  • Let containers grow with content; prefer min-height over fixed heights when possible.
  • Keep interactions operable (keyboard, touch, pointer) at every size; ensure focus stays visible.
  • Support user overrides for text size and spacing without clipping or overlap.

Avoid

  • Breakpoint-only layouts that fall apart between sizes.
  • Fixed heights on text containers that cause clipping when text grows or wraps.
  • Horizontal scrolling for standard page content due to rigid widths or unwrapped tables.
  • Absolute positioning for essential content or controls that can overlap at intermediate widths.
  • Hard-coded type sizes in px that don’t respond to user settings.
  • Hover-only access to critical navigation or controls without a keyboard/touch equivalent.

Audit Checks

  • Reflow check: At narrow widths, confirm no content/control is lost and no two-direction scrolling is required.
  • Zoom check: Increase zoom and confirm navigation, headings, and controls remain usable and visible.
  • Text growth check: Confirm headings and buttons wrap and remain readable without clipping.
  • Interaction check: Tab through controls at multiple sizes; verify focus visibility and no off-screen traps.
FeatureSupportNotes
vw (viewport width unit)FullSupported in all major browsers. fall back for dvw
dvw (dynamic viewport width unit)PartialSupported in Safari 16+, Chrome 108+, Edge 108+, Firefox 109+.
clamp()FullFully supported in all modern browsers.
CSS Variables (var())FullFully supported except in legacy IE (Internet Explorer).

Stackable Containers

Stackable: In general don't stack sections inside other section blocks use divs inside of a section.

Best Practice: Avoid nesting multiple <section> or container-like layout wrappers (e.g., .container-* elements) unless it serves a specific design or structural need. Overuse can increase layout complexity and reduce maintainability. Use inner containers only when you need to constrain or realign content differently within a full-width or semantically distinct parent section.

WCAG and semantic HTML spec allows nested <section> elements as long as the nested section has its own heading (<h2>, <h3>, etc.) to describe the content.

Ensure interactive components within containers (e.g., modals, tabs, accordions) remain focusable, usable via keyboard, and visually aligned at all responsive breakpoints aligning with WCAG 2.1.1 (Keyboard), 2.4.7 (Focus Visible), and 1.3.4 (Orientation).



Dark Mode - needs work

It seems that you have reduce motion enabled!