Skip to main content

Module 5 · Web testing

Responsive behaviour and accessibility basics

Check layouts across screen sizes, and the first accessibility checks every tester can do.

About 11 min reading and 15 min practice (estimates)

Loading progress…

Read

Learning objectives

  • Test a page at phone, tablet and desktop widths, including zoom.
  • Run basic keyboard, focus, label and contrast checks.
  • Know the limits of automated accessibility tools.

Explanation

Responsive testing: use the browser's device toolbar to try common widths (around 360–390 px for phones, 768 px for tablets, 1280 px and wider for desktops), both orientations, and browser zoom at 200%. Look for content that is cut off, overlapping, or causes sideways scrolling, and controls too small to tap. Emulation is a good start, but check important flows on a few real devices too.

Accessibility means people can use the product with different abilities and tools — keyboard only, screen readers, magnification. The Web Content Accessibility Guidelines (WCAG) define testable criteria. Basic checks anyone can do:

  • Keyboard: reach and use every control with Tab, Shift+Tab, Enter and Space, in a sensible order, without getting trapped.
  • Focus: you can always see which element has focus.
  • Labels: every form field has a visible label, and error messages say what to fix.
  • Contrast: normal text needs at least 4.5:1 against its background (3:1 for large text) at WCAG level AA.
  • Images and icons that convey meaning have text alternatives; headings form a logical outline.

Automated tools such as Lighthouse or axe find some issues quickly, but they cannot judge everything — for example whether a label actually makes sense. Combine them with manual checks.

Example: findings on a fictional checkout form

  • At 390 px, the order summary pushes the page wider than the screen (sideways scroll).
  • The Wilayat field uses placeholder text instead of a label; the hint disappears while typing.
  • After a failed submit, focus stays on the button; screen-reader users aren't told which field failed.
  • In Arabic, the price appears as "OMR 24.500" in one place and "24.500 OMR" in another.

Common mistakes

  • Testing only at your own screen size.
  • Running one automated scan and calling the page accessible.
  • Checking keyboard access without checking that focus is visible.

Try

Practise what you just read. Answers are checked here; nothing is graded publicly or counts toward Bug Arena.

Exercise

Open Bug Arena Practice at a phone width, then use only the keyboard to add a product and reach the checkout form. Write a short checklist (5–8 items) you would use for this flow, and note anything you observed.

Write your answer first, then compare it with the sample solution. It stays on this page only and isn't sent anywhere.

Review

Check yourself — you should now be able to:

  • Test a page at phone, tablet and desktop widths, including zoom.
  • Run basic keyboard, focus, label and contrast checks.
  • Know the limits of automated accessibility tools.

Practise in QA Lab

References

Continue

When you’re ready, mark the lesson complete in the Try step and move on.

Marked as read when you reach the end of the lesson.