Frontend Fundamentals: HTML, CSS, and Responsive Styling Questions

Plan overview (goal: make existing canvas charts fully operable & perceivable)

1. Quick wins (low risk, high value)

• Add an accessible data table alongside each chart (HTML <table> is semantic, screen-reader friendly). Include summary, captions, column headers, sortable rows if interactive.
• Add an aria-describedby and role="img" to the canvas so assistive tech gets a short description and link to the data table.
  • Example attributes: role="img" aria-labelledby="chart-title" aria-describedby="chart-desc"

2. Keyboard navigation / exploration mode

• Provide a toggle "Explore chart with keyboard" that switches into focusable mode.
• Build a roving-tabindex/focus management on a logical offscreen DOM representation of chart elements (points/series) — e.g., <button> or <a> elements placed in an offscreen container with .sr-only styling.
• Keyboard interactions: Arrow keys to move focus between points, Enter/Space to "activate" (open tooltip), Home/End to jump series start/end, Esc to exit mode.
• On focus, expose full data: label, x/y values, series name, and percent/summary.

3. Announcing updates

• Use an aria-live region (aria-live="polite" or "assertive" depending on urgency) to announce dynamic changes: filtering, zoom, hover-equivalent updates.
• When data updates, post concise messages: "Chart updated: showing 12 of 50 items; highest value is X (series Y)."

4. Offscreen accessible DOM vs converting to SVG — trade-offs

• Convert to SVG:
  • Pros: native DOM nodes, automatic semantics, easier keyboard/ARIA, CSS styling, better testability.
  • Cons: performance/memory impact with very large datasets, refactor cost.
• Offscreen accessible DOM (mirror of canvas):
  • Pros: minimal visual refactor, retains canvas rendering performance, faster delivery.
  • Cons: duplication risk (two sources of truth), more maintenance, potential synchronization bugs.
• Recommendation: If datasets are moderate and interactivity is rich, prefer SVG conversion for long-term maintainability. For high-point/real-time charts where performance matters, implement an authoritative data model and generate an offscreen accessible DOM synced from that model.

5. Implementation & QA checklist

• Create data-export (CSV/JSON) and visible data table; link via aria-controls.
• Implement exploration mode with roving tabindex and keyboard handlers; ensure focus is visible.
• Add aria-describedby/aria-labelledby on canvas; provide short and long descriptions.
• Add aria-live region for announcements; debounce updates to avoid spam.
• Sync offscreen DOM via central data model; unit-test synchronization and keyboard flows.
• Test with NVDA, VoiceOver, JAWS, keyboard-only, and users with assistive tech.

6. Metrics & rollout

• Start with data tables + live region + aria descriptions (1 sprint).
• Add keyboard exploration next sprint.
• Decide SVG migration based on performance profiling and maintenance cost within 2–4 sprints.

This approach balances immediate accessibility needs with long-term maintainability and performance considerations.

Brief summary
I’d pick units based on what they should track: px for absolute control, % for container-relative sizing, em/rem for typographic/scoped scaling, vw/vh for viewport-driven layouts.

Per-unit details

• px

  • Calculated: device pixels (CSS px).
  • Use: precise UI components, borders, icons.
  • Pitfall: not responsive; ignores user font-size preferences.

• %

  • Calculated: percentage of the parent element’s relevant dimension (width/height).
  • Use: fluid layouts, grid column widths.
  • Pitfall: collapsing when parent has no explicit size (height % often fails).

• em

  • Calculated: multiple of the computed font-size of the element (inherited).
  • Use: component-local scaling (padding relative to text).
  • Pitfall: compounding effect when nested can lead to unexpected sizes.

• rem

  • Calculated: multiple of the root (html) font-size.
  • Use: consistent typographic scale and spacing across app.
  • Pitfall: changing root font-size affects entire UI (careful with user zoom).

• vw / vh

  • Calculated: 1vw = 1% of viewport width; 1vh = 1% of viewport height.
  • Use: full-bleed sections, responsive hero sizing, fluid type.
  • Pitfall: can cause layout jumps on mobile when browser chrome resizes.

Example — fluid typography combining rem + vw

html { font-size: 16px; }

/* base scales with root, adds viewport-based fluidity */
h1 {
  font-size: calc(1.5rem + 2vw);
  line-height: 1.1;
  margin-bottom: 0.5rem;
}

/* container width fluid with percent and max */
.container {
  width: 90%;
  max-width: 1200px;
  margin: 0 auto;
}

Reasoning: rem ensures predictable base scale, vw adds viewport responsiveness without nesting issues.

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.

Definition: browsers enforce cross-origin restrictions (CORS) for XHR/fetch, resource integrity and font loading rules, and iframe embedding policies (X-Frame-Options/Sandbox). Designers must know these can block assets or change behavior.
Two example features and mitigations:

1. Custom webfonts hosted on third-party domain: browsers block fonts unless Access-Control-Allow-Origin permits origin. Mitigation: host fonts on same origin or ensure CDN sets Access-Control-Allow-Origin: * (or your origin) and proper CORS headers; use font-display: swap to avoid blocking text rendering.
2. Animated hero composed from cross-origin images or an iframe embedding a third-party widget that modifies layout: images used in canvas or CSS filters require CORS-enabled responses (tainted canvas otherwise). Mitigation: request images from CORS-enabled endpoints (Access-Control-Allow-Origin) or proxy images through your server; for iframes, work with provider to allow embedding (provide origin allow-list) or use postMessage API for integration rather than DOM access.
   Designer implications: prefer same-origin hosting for critical assets, define graceful fallbacks for blocked resources (system fonts, placeholder images), and coordinate with engineering/third parties to ensure CORS headers and embedding policies are correctly configured.

Approach (brief)
Use a semantic container with two children (e.g., main + aside). Use Flexbox with gap for spacing and a media query at 600px to switch between row (two columns) and column (stacked). Make images fluid and text wraps naturally.

HTML

<section class="two-col" aria-label="Two column layout">
  <main>
    <h2>Article</h2>
    <p>Some paragraph text that will wrap inside the column.</p>
    <img src="image.jpg" alt="Descriptive alt text">
  </main>
  <aside>
    <h3>Sidebar</h3>
    <p>Sidebar content that also wraps appropriately.</p>
    <img src="side.jpg" alt="Decorative or descriptive text">
  </aside>
</section>

CSS

.two-col {
  display: flex;
  flex-direction: column; /* default: stacked */
  gap: 16px;
  align-items: stretch;
}

.two-col > * {
  box-sizing: border-box;
  padding: 8px;
}

/* Images responsive */
.two-col img {
  max-width: 100%;
  height: auto;
  display: block;
}

/* Two-column layout at >=600px */
@media (min-width: 600px) {
  .two-col {
    flex-direction: row;
  }
  .two-col > * {
    flex: 0 0 50%; /* each column takes 50% */
  }
}

Notes

• Uses gap (modern browsers) to provide 16px spacing without margin hacks.
• Semantic elements (main/aside) improve accessibility and structure.
• Images won't overflow due to max-width:100% and height:auto.