Responsive UI: Responsiveness, Accessibility, Maintainability & Browser Compatibility

Interview Question

Your team needs to build a responsive UI that works consistently across desktop, tablet, and mobile devices.

How would you ensure:

Responsiveness

Accessibility

Maintainability

Browser compatibility

Short Interview Answer

For a React-based enterprise application, I would approach responsive UI as a combination of responsive design, accessibility standards, reusable components, and cross-browser testing.

I would use a mobile-first responsive design with CSS Grid, Flexbox, relative units, and standardized breakpoints. For accessibility, I would follow WCAG guidelines, use semantic HTML, keyboard navigation, proper labels, focus management, and screen-reader support.

For maintainability, I would build reusable React components around a common design system, enforce coding standards with ESLint and Prettier, and keep business logic separated from presentation.

For browser compatibility, I would define supported browsers using Browserslist, use appropriate transpilation/polyfills, and validate the application through automated and cross-browser testing using tools such as Playwright or BrowserStack.

1. Responsiveness

The goal is to ensure that the UI adapts naturally to different screen sizes and input devices.

Key practices

Follow a mobile-first approach using CSS media queries.
Use Flexbox and CSS Grid instead of fixed-position layouts.
Prefer relative units such as:
- %
- rem
- em
- vw
- vh
Define standard breakpoints for:
- Mobile
- Tablet
- Desktop
- Large desktop, if required
Make images and media responsive using max-width: 100%.
Use responsive typography and spacing.
Avoid unnecessary hard-coded widths and heights.
Build reusable React components that adapt to the available space instead of maintaining separate desktop and mobile implementations.

Example

.container {
  width: 100%;
  padding: 1rem;
}

@media (min-width: 768px) {
  .container {
    max-width: 1200px;
    margin: auto;
  }
}

Responsive Architecture

flowchart TD
    A[User Device] --> B{Viewport Size}
    B -->|Mobile| C[Mobile Layout]
    B -->|Tablet| D[Tablet Layout]
    B -->|Desktop| E[Desktop Layout]

    C --> F[Reusable React Components]
    D --> F
    E --> F

    F --> G[Responsive CSS]
    G --> H[Consistent UI]

Important Principle

I would avoid creating completely different implementations such as:

DesktopComponent
MobileComponent
TabletComponent

unless the interaction itself is fundamentally different.

Instead, I would prefer:

Reusable React Component
        |
        +-- Responsive CSS
        |
        +-- Responsive Layout
        |
        +-- Responsive Interaction

2. Accessibility

I would follow WCAG guidelines and make accessibility part of development rather than treating it as a final testing activity.

Key practices

Semantic HTML

Use meaningful HTML elements:

<header>
<nav>
<main>
<section>
<article>
<button>
<form>
<footer>

Instead of creating everything using generic <div> elements.

Forms

Every form field should have an accessible label.

<label htmlFor="email">Email</label>
<input
  id="email"
  type="email"
/>

This is better than relying only on:

<input placeholder="Email" />

Users should be able to use the application without a mouse.

Important areas include:

Buttons
Links
Forms
Dropdowns
Modals
Menus
Tabs
Tables
Pagination

Focus Management

Focus should remain visible and should be managed correctly when opening and closing components such as dialogs.

For example:

Open Modal
    ↓
Move focus into Modal
    ↓
User interacts using keyboard
    ↓
Close Modal
    ↓
Return focus to triggering element

Use semantic HTML first.

Use ARIA attributes when native HTML semantics are not sufficient.

Examples include:

aria-label
aria-labelledby
aria-describedby
aria-expanded
aria-live
aria-hidden

Visual Accessibility

Check:

Color contrast
Font readability
Focus indicators
Error messages
Non-color indicators
Responsive text scaling

Accessibility Testing

I would include:

Keyboard-only testing
Screen-reader testing
Automated accessibility testing
Lighthouse
axe
React Testing Library accessibility assertions where appropriate

3. Maintainability

For maintainability, I would establish a reusable component architecture rather than allowing every feature team to build UI independently.

Suggested React Structure

src/
├── components/
│   ├── Button/
│   ├── Modal/
│   ├── Table/
│   └── Form/
├── pages/
├── hooks/
├── services/
├── styles/
├── utils/
└── types/

Reusable Components

Common components should be standardized.

Examples:

Button
Input
Select
Modal
Dropdown
Table
Pagination
Card
Toast
DatePicker
LoadingSpinner

Instead of having multiple slightly different implementations:

UserButton
AdminButton
ProductButton
PaymentButton

when the underlying behavior and visual design are the same.

Design System

I would establish common design tokens for:

Colors
Typography
Spacing
Border radius
Shadows
Breakpoints
Z-index levels
Component states

For example:

:root {
  --spacing-sm: 0.5rem;
  --spacing-md: 1rem;
  --spacing-lg: 1.5rem;

  --radius-sm: 4px;
  --radius-md: 8px;

  --breakpoint-tablet: 768px;
  --breakpoint-desktop: 1024px;
}

This reduces duplicated styling and makes global design changes easier.

Separation of Responsibilities

I would keep UI, business logic, and API communication separated.

flowchart LR
    A[React Page] --> B[Presentation Components]
    B --> C[Custom Hooks]
    C --> D[Service Layer]
    D --> E[REST API]
    E --> F[Backend Services]

    B --> G[Design System]
    C --> H[Reusable Utilities]

For example:

Component
   |
   +-- Displays UI
   |
   +-- Receives props
   |
   +-- Handles UI events
          |
          v
      Custom Hook
          |
          v
      Service Layer
          |
          v
       REST API

This makes components easier to test and reuse.

4. Code Quality

I would establish common engineering standards across the team.

Tools

ESLint
Prettier
TypeScript
Husky/pre-commit hooks where appropriate
Unit/component tests
Code review
CI/CD quality gates

Principles

Avoid duplicated code.
Keep components focused.
Use meaningful names.
Avoid unnecessary abstractions.
Keep business logic outside presentation components.
Prefer composition over deeply nested component inheritance patterns.
Document reusable components.
Use Storybook where a component library needs independent development and documentation.

5. Browser Compatibility

Before development, I would define a supported browser matrix.

For example:

Browser	Support
Chrome	Current supported versions
Edge	Current supported versions
Firefox	Current supported versions
Safari	Current supported versions
Mobile Safari	Supported
Chrome Android	Supported

The exact versions should be agreed with product/business requirements.

Browserslist

I would use Browserslist to communicate browser support to the build and tooling ecosystem.

Example:

> 1%
last 2 versions
not dead
not IE 11

The actual configuration should be based on the application’s real user base and business requirements.

Transpilation and Polyfills

Where necessary:

Use Babel/transpilation through the project’s build tooling.
Add polyfills only for APIs that actually need support.
Avoid unnecessarily shipping large polyfill bundles.
Verify third-party library browser support.

CSS Compatibility

Before adopting a CSS feature, I would verify browser support.

For example:

CSS Feature
     |
     v
Browser Support Check
     |
     +---- Supported ----> Use
     |
     +---- Partial ------> Add fallback
     |
     +---- Unsupported --> Alternative implementation

I would also use progressive enhancement where appropriate.

6. Cross-Browser Testing

I would combine automated tests with manual validation.

Test Matrix

flowchart TD
    A[Application Build] --> B[Automated Tests]

    B --> C[Unit Tests]
    B --> D[Component Tests]
    B --> E[Accessibility Tests]
    B --> F[E2E Tests]

    A --> G[Responsive Testing]
    G --> H[Mobile]
    G --> I[Tablet]
    G --> J[Desktop]

    A --> K[Cross-Browser Testing]
    K --> L[Chrome]
    K --> M[Firefox]
    K --> N[Edge]
    K --> O[Safari]

Tools

Depending on project requirements:

Playwright
Cypress
BrowserStack
Selenium
Chrome DevTools
Firefox Developer Tools
Safari Web Inspector
Lighthouse
axe

7. Testing Strategy

I would use multiple layers of testing.

flowchart TD
    A[Code Change] --> B[Linting]
    B --> C[Unit Tests]
    C --> D[Component Tests]
    D --> E[Accessibility Tests]
    E --> F[Responsive Tests]
    F --> G[Cross-Browser Tests]
    G --> H[E2E Tests]
    H --> I[CI/CD]
    I --> J[Production]

Unit Tests

Test isolated utilities and business logic.

Component Tests

Test:

Rendering
User interactions
Props
States
Error conditions

Accessibility Tests

Validate:

Labels
Roles
Keyboard behavior
Accessible names
Focus behavior

E2E Tests

Validate complete user journeys such as:

Login
  ↓
Dashboard
  ↓
Search
  ↓
Open Details
  ↓
Submit Form
  ↓
Success

8. Responsive Design Checklist

Before releasing a feature, I would verify:

9. Accessibility Checklist

10. Maintainability Checklist

11. Browser Compatibility Checklist

12. Lead-Level Approach

As a lead, I would not consider this only a frontend developer responsibility. I would establish the standards at the team level.

My approach would be:

flowchart TD
    A[Define Requirements] --> B[Browser Support Matrix]
    B --> C[Responsive Design System]
    C --> D[Accessibility Standards]
    D --> E[Reusable React Components]
    E --> F[Implementation]
    F --> G[Automated Testing]
    G --> H[Cross-Browser Validation]
    H --> I[Code Review]
    I --> J[CI/CD Quality Gates]
    J --> K[Production Monitoring]

Team-Level Standards

I would establish:

Supported browser versions.
Standard responsive breakpoints.
Design tokens.
Accessibility requirements.
Reusable component standards.
Testing standards.
Definition of Done.
CI/CD quality gates.

This prevents every developer from making their own decisions for common UI concerns.

13. Strong Lead-Level Interview Answer

“I would address this at four levels: responsive design, accessibility, maintainability, and compatibility.

For responsiveness, I would use a mobile-first approach with Flexbox and CSS Grid, responsive units, standardized breakpoints, and reusable React components. I would avoid fixed layouts and separate desktop/mobile implementations unless the user experience is fundamentally different.

For accessibility, I would follow WCAG guidelines and use semantic HTML, proper form labels, keyboard navigation, focus management, sufficient color contrast, and screen-reader support. Accessibility testing would be part of the development and CI process rather than something done only before release.

For maintainability, I would establish a reusable component library and design system with common tokens for colors, typography, spacing, and breakpoints. I would separate presentation, business logic, and API communication using components, hooks, and service layers. ESLint, Prettier, TypeScript, testing, and code reviews would enforce consistency.

For browser compatibility, I would first define a supported browser matrix based on our actual users and business requirements. I would configure Browserslist, use appropriate transpilation and polyfills, verify CSS and third-party library compatibility, and test critical flows across Chrome, Firefox, Edge, Safari, and mobile browsers.

Finally, I would automate as much as possible through unit tests, component tests, accessibility checks, responsive testing, and E2E tests using tools such as Playwright or Cypress. As a lead, my focus would be to establish these standards at the team level so that responsive, accessible, and maintainable UI becomes part of our normal development process rather than an afterthought.“

14. What Interviewers Are Looking For

For a senior/lead candidate, the interviewer is usually looking beyond:

“I use media queries.”

A stronger answer demonstrates that you understand the engineering process around UI development.

They are looking for evidence that you can think about:

                    UI Quality
                       |
        +--------------+--------------+
        |              |              |
   Responsive     Accessible     Maintainable
        |              |              |
        +--------------+--------------+
                       |
                Cross-Browser
                       |
                       v
               Production Quality

The strongest answer connects:

Design → Component Architecture → Accessibility → Testing → Browser Compatibility → CI/CD → Team Standards

15. Key Takeaway

A production-ready responsive React application should not be treated as simply a collection of CSS media queries.

A lead-level implementation should provide:

Area	Approach
Responsiveness	Mobile-first + Grid/Flexbox + responsive units
Accessibility	WCAG + semantic HTML + keyboard + screen readers
Maintainability	Reusable components + design system + separation of concerns
Code Quality	TypeScript + ESLint + Prettier + code reviews
Browser Compatibility	Browserslist + transpilation + selective polyfills
Testing	Unit + component + accessibility + E2E
Cross-browser	Chrome + Firefox + Edge + Safari + mobile
Team Process	Standards + CI/CD quality gates + Definition of Done

Final Interview Summary

Responsive → Mobile-first design and flexible layouts.

Accessible → WCAG, semantic HTML, keyboard support, and screen readers.

Maintainable → Reusable components, design system, clean architecture, and coding standards.

Compatible → Supported browser matrix, Browserslist, appropriate build tooling, and cross-browser testing.

Lead-level differentiator → Turn all of these into team-wide engineering standards and automated quality gates rather than relying on individual developer discipline.

Responsive UI: Responsiveness, Accessibility, Maintainability & Browser Compatibility

Interview Question

Short Interview Answer

1. Responsiveness

Key practices

Example

Responsive Architecture

Important Principle

2. Accessibility

Key practices

Semantic HTML

Forms

Keyboard Navigation

Focus Management

Screen Reader Support

Visual Accessibility

Accessibility Testing

3. Maintainability

Suggested React Structure

Reusable Components

Design System

Separation of Responsibilities

4. Code Quality

Tools

Principles

5. Browser Compatibility

Browserslist

Transpilation and Polyfills

CSS Compatibility

6. Cross-Browser Testing

Test Matrix

Tools

7. Testing Strategy

Unit Tests

Component Tests

Accessibility Tests

E2E Tests

8. Responsive Design Checklist

9. Accessibility Checklist

10. Maintainability Checklist

11. Browser Compatibility Checklist

12. Lead-Level Approach

Team-Level Standards

13. Strong Lead-Level Interview Answer

14. What Interviewers Are Looking For

15. Key Takeaway

Final Interview Summary