# Responsive Design and Accessibility

## Principle

Mobile should be as capable as reasonably possible, but it does not need to visually imitate desktop.

Responsive design should transform workflows when necessary rather than simply shrinking them.

## Breakpoint strategy

Use content-driven breakpoints based on when layouts stop working effectively.

Do not design around a single desktop resolution.

Test at minimum:

- small mobile,
- large mobile,
- tablet portrait,
- tablet landscape,
- laptop,
- desktop,
- wide desktop.

## Mobile navigation

Desktop sidebar should transform into a mobile-specific navigation pattern.

Likely options:

- bottom navigation for major destinations,
- a secondary menu for less frequent destinations,
- contextual top bar actions.

Final decision should be validated against the number of important destinations.

## Jobs

Desktop:

- table by default,
- board available.

Mobile:

- cards or structured list,
- essential job information visible immediately,
- filters in a mobile sheet/drawer,
- board may remain available if usable, but should not be forced if it becomes cumbersome.

## Job detail

Use stacked mobile sections with a sticky or easy-to-access action area.

Avoid tiny multi-column layouts.

## Dashboard

Desktop:

- resizable/reorderable grid.

Mobile:

- single-column widget feed,
- reorder/hide still supported where practical,
- resize controls may be omitted if they do not make sense.

## CV builder

Desktop can use editor + live preview side by side.

Mobile should use an alternate workflow, for example:

- Edit mode
- Preview mode

Do not force a two-pane desktop editor onto a phone.

## Forms

- clear labels,
- adequate touch targets,
- errors close to fields,
- preserve entered data on validation failure,
- avoid unnecessary modal nesting,
- support browser autofill where appropriate.

## Keyboard accessibility

Desktop users should be able to:

- navigate controls with keyboard,
- operate menus/dialogs,
- use command palette,
- dismiss dialogs with Escape where appropriate,
- understand visible focus state.

## Screen readers

Use semantic HTML and correct ARIA only where needed.

Do not use ARIA as a substitute for semantic structure.

## Contrast

Light and dark modes must meet appropriate contrast requirements for:

- text,
- icons,
- buttons,
- status indicators,
- focus states,
- disabled states.

## Colour independence

Status must not rely on colour alone.

Use text/icon/shape cues as well.

## Motion

Respect reduced-motion settings.

Essential state changes should remain understandable without animation.

## Localisation

Test both English and Norwegian throughout the responsive UI.

Norwegian text may be longer than English in some areas; layouts must tolerate this.

Avoid hard-coded control widths that only fit English labels.

## Content stress testing

Test with:

- very long company names,
- long job titles,
- long Norwegian labels,
- missing data,
- large numbers of jobs,
- zero jobs,
- many status values,
- long CV content,
- multiple-page CVs.