Frontend Fundamentals: HTML, CSS, and Responsive Styling Questions

Overview
I’d compare each ARIA composite by keyboard model, required ARIA state/props, implementer responsibilities, and pitfalls — finishing with when to prefer native elements.

Combobox

• Keyboard: Up/Down to navigate suggestions, Enter to commit, Esc to close, Typing to filter, Tab to move focus out.
• ARIA: role="combobox" + aria-expanded, aria-controls, aria-activedescendant; list role="listbox" and options role="option".
• Responsibilities: manage focus vs. active descendant, announce selection changes, virtualization for large lists.
• Pitfalls: confusing focus (focus on input vs. list), not updating aria-activedescendant, failing screen reader announcements.

Listbox

• Keyboard: Up/Down, Home/End, PageUp/PageDown, Space/Enter to select; Shift/Ctrl for multi-select patterns.
• ARIA: role="listbox", options role="option", aria-selected for multi/single select.
• Responsibilities: keyboard focus management, selection model, ensure roving tabindex or aria-activedescendant.
• Pitfalls: mixing tabindex on options, no clear selection announcements.

Tree

• Keyboard: Up/Down navigation; Right to expand/focus child; Left to collapse/parent; Home/End.
• ARIA: role="tree", role="treeitem", aria-expanded on branches, aria-level, aria-setsize, aria-posinset.
• Responsibilities: manage hierarchical focus, lazy loading children, maintain aria-level/setsize/posinset.
• Pitfalls: incorrect semantics for nested lists, not updating positional properties, poor keyboard handling in nested contexts.

Grid

• Keyboard: Arrow keys move within cells; Enter/Space to activate cell; F2 to enter edit mode (author-defined); Home/End, Page keys.
• ARIA: role="grid" or "treegrid", role="row", role="gridcell" or "rowheader", aria-colcount/rowcount optionally.
• Responsibilities: manage cell/focus navigation, edit mode vs navigation mode, support for selection and headers.
• Pitfalls: failing to separate navigation vs edit mode, not exposing cell roles or keyboard commands.

When to prefer native

• Use <select> for simple single/multi selects and <table> for tabular data whenever possible — browsers provide built-in keyboard, focus, and AT support. Prefer native when behavior matches needs (filtering or complex editing are reasons to implement ARIA composites).

I’d implement these with progressive enhancement, test with VoiceOver/NVDA/JAWS, and include automated a11y tests and keyboard-only user testing.

Approach & trade-offs

I prefer content-driven, mobile-first breakpoints: let layout and component behavior drive where breakpoints land rather than targeting device models. Device-driven can become brittle as device sizes proliferate; content-driven ensures components look good at their natural widths.

How many breakpoints

Aim for a small, pragmatic set: 4–6. Too few forces awkward compromises; too many increases CSS complexity and maintenance. For most component libraries 4 breakpoints balance flexibility and simplicity.

Proposed set (mobile-first, min-width)

• 0px — base (phones, single-column)
• 480px — small phones / compact inputs — adjust padding/stacking
• 768px — tablets / two-column layouts
• 1024px — small desktops / medium containers
• 1280px — large desktops / wide content

Justification: each point corresponds to clear content changes (stack → columns, nav changes, container widening). Values align with common grid/container needs rather than specific devices.

Documentation for design system

• Visual spec: screenshots and interactive playground at each breakpoint
• Token table: breakpoint names, min-width values, intended use
• Examples: component rules per breakpoint (e.g., nav becomes hamburger <768px)
• Guidance: when to create new breakpoint, performance/accessibility notes, testing checklist (viewport sizes, zoom, RTL)
• Semantic names (xs, sm, md, lg, xl) + usage rules to keep teams consistent.

This yields predictable, maintainable responsive behavior for developers and designers.

A breakpoint is a viewport width (or condition) where the layout or styles change to suit different screen sizes. Example 1: Content-driven breakpoint — change layout when a component’s natural width wraps or overflows (e.g., switch from 3 columns to 1 at 720px because cards compress). This prioritizes visual integrity over devices. Example 2: Device-targeted breakpoint — target common device widths like 480px (small phones) and 1024px (tablets) when analytics show many users on those sizes. Choose based on content behavior and user metrics, not arbitrary device lists.

Checklist for interactive components (buttons, inputs, dialogs):

1. Keyboard focus order & visible focus styles — Ensure logical tab order and clear focus indicator (not removed). Important so keyboard-only users can navigate and know current focus.

2. ARIA roles & attributes — Use role="button"/role="dialog", aria-expanded, aria-controls, aria-labelledby. Provides semantic meaning to assistive tech.

3. Contrast & hit target size — Text/icon contrast >=4.5:1, interactive targets >=44x44px. Improves readability and tap accuracy for low vision and motor-impaired users.

4. Labeling & instructions — Provide visible labels and aria-label/aria-describedby for extra context (errors, helper text). Prevents ambiguity for screen reader users.

5. Announcements for dynamic changes — Use aria-live or role=alert for status updates and opened/closed dialogs. Ensures assistive tech users receive state changes.

6. Focus management for dialogs & menus — Trap focus when open, return focus to triggering control on close. Prevents focus loss and disorientation.

7. Avoid relying on color/hover — Don’t use color alone to convey state; provide text or icon indicators and ensure hover-only interactions have keyboard alternatives.

8. Motion preferences — Respect prefers-reduced-motion: reduce/disable non-essential animations to avoid vestibular issues.

Each item maps directly to common accessibility failures and should be included in the design spec with examples and acceptance criteria.

Explaination of values

• tabindex="0"
  Element is focusable in natural tab order (after native tabbables) and receives focus when tabbing. Use for custom controls that should be keyboard reachable (e.g., a clickable div made accessible).

• tabindex="-1"
  Element is programmatically focusable (element.focus()) but removed from the keyboard tab sequence. Useful for focus management like routing/skip-links, modal dialogs, or focusing live regions without stealing the next Tab.

• positive tabindex (e.g., tabindex="1")
  Inserts element into a custom, prioritized tab order; lower numbers focused first. It overrides document order and native behavior.

When tabindex="-1" is useful

• Skip-to-content links: move focus to the main landmark without adding an extra tab stop.
• After closing a modal: focus the element that opened the modal programmatically.
• Focusing error summaries or live regions so screen readers announce content without altering tab flow.

Why positive tabindex is discouraged

• Creates maintenance and accessibility problems in large apps:
  • Hard to reason about global ordering as components change.
  • Breaks expected document-order navigation for keyboard users and assistive tech.
  • Leads to conflicts when multiple components assign numbers.
  • Prefer DOM order + tabindex="0" and explicit programmatic focus management.

Example: make a div focusable but not tabbable:

<div tabindex="-1" id="error-summary">Form submission failed</div>
<script>
  document.getElementById('error-summary').focus();
</script>