Files
jobtrackingapp/docs/redesign/RESPONSIVE_ACCESSIBILITY.md
cesnimda 1bbbd05ed5
CI and Deploy / test (push) Failing after 34s
CI and Deploy / deploy (push) Has been skipped
docs(redesign): record product brief and phased audit handoff
2026-09-09 18:21:48 +02:00

3.0 KiB

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.