Learning intentions
- Understand the purpose of testing a website before publishing it
- Know the four types of testing: functional, browser compatibility, accessibility, and usability
- Know what accessibility means in web design and how to check for common accessibility issues
- Know what usability means and how it differs from functional testing
- Understand how to document testing using a test plan with expected and actual results
Success criteria
- I can name and describe all four types of web testing
- I can explain the difference between functional testing and usability testing
- I can identify accessibility problems in a described or shown webpage
- I can complete a test plan table with expected and actual results
- I can explain why testing in multiple browsers is necessary
Answer before the lesson begins.
1. Which type of testing checks whether a website can be used by people with disabilities?
2. What does alt text on an image do?
3. A developer tests their website in Chrome but not in Firefox or Safari. What type of testing have they failed to carry out?
Key vocabulary
alt attribute. Screen readers read it aloud for visually impaired users. Also displayed if the image fails to load.Testing: Browsers, Accessibility and Usability
Why do we test websites?
A website may look correct on the developer's computer but behave differently for users — broken links, missing images, distorted layouts on different screen sizes, or content that screen-reader users cannot access. Testing finds errors before publishing so they can be fixed before they affect real users.
Testing should always be planned in advance, documented, and compared against what was expected. Without a test plan, testing is inconsistent and errors are easy to miss.
The four types of testing
At N5 level, there are four types of testing you need to know:
| Type | What it checks | Example test |
|---|---|---|
| Functional | Do all features work as intended? | Click the "Contact" link — does it navigate to contact.html? |
| Browser compatibility | Does the site look and work the same in different browsers? | Open the site in Chrome, Firefox, and Safari — does the nav bar appear correctly in all three? |
| Accessibility | Can people with disabilities use the site? | Do all images have alt text? Is there enough colour contrast? Can you navigate using only the keyboard? |
| Usability | Is the site easy to navigate and understand for the target audience? | Can a new visitor find the contact page within 30 seconds? Is the font large enough to read comfortably? |
Test a website against all four criteria before publishing
Browser compatibility
Different browsers use different rendering engines — Chrome uses Blink, Safari uses WebKit, Firefox uses Gecko. Each engine may interpret HTML and CSS slightly differently, meaning a page that looks perfect in Chrome may have a broken layout in Safari or Firefox.
Good practice is to test in at least three browsers: Chrome, Firefox, and Safari. Edge is also commonly tested. Mobile browsers (on phones and tablets) should be tested too, as screen sizes differ significantly from desktop.
Accessibility
Accessibility means making websites usable for everyone, including people who:
- Use screen readers (software that reads page content aloud — requires alt text on images)
- Have visual impairments (require sufficient colour contrast, large enough font sizes)
- Use keyboard-only navigation (must be able to tab through all interactive elements without a mouse)
- Have cognitive disabilities (benefit from clear, simple language and logical page structure)
The WCAG (Web Content Accessibility Guidelines) set international standards for accessibility. Common requirements include:
- All images have meaningful
alttext - Colour contrast ratio is at least 4.5:1 for normal text (dark text on light background)
- Font sizes are legible (not below 12px for body text)
- Interactive elements are reachable using the Tab key
Usability
A website can pass all functional tests — every link works, every image loads — and still be very difficult to use. Usability is about whether real users in the target audience can navigate and use the site effectively.
Usability considerations include:
- Consistent navigation — the nav bar should appear in the same position on every page
- Readable content — appropriate font size, line spacing, and contrast for the target audience
- Logical structure — content is organised in an order that makes sense to users
- Appropriate file sizes — large images slow loading times, which reduces usability, especially on mobile connections
- Appropriate language — vocabulary matched to the intended audience (a children's site should not use complex academic language)
Test plans and test evidence
A test plan is created before testing begins. It lists every test to be carried out, the expected result, and space for the actual result and pass/fail. After testing, test evidence (such as screenshots) is collected to prove tests were carried out.
If the actual result does not match the expected result, the test has failed — the developer must investigate, fix the bug, and retest.
| Test # | Description | Expected result | Actual result | Pass/Fail |
|---|---|---|---|---|
| 1 | Home page loads in Chrome | Page loads without errors | Page loaded correctly | Pass |
| 2 | Nav "Gallery" link clicked | Navigates to gallery.html | 404 error shown | Fail |
| 3 | Logo image on home page | Image displays with alt text "School logo" | Image displayed; alt text present | Pass |
| 4 | Nav bar in Firefox | Nav bar appears identically to Chrome | Nav bar rendered correctly | Pass |
Worked examples
A developer builds a three-page school website (Home, Gallery, Contact). Before publishing, they create this test plan:
| Test # | Description | Expected result | Actual result | Pass/Fail |
|---|---|---|---|---|
| 1 | Home page loads in Chrome | Page displays with correct layout and all images | Page loaded correctly, all images visible | Pass |
| 2 | "Contact" nav link clicked from Home | Browser navigates to contact.html | Navigated to contact.html correctly | Pass |
| 3 | Gallery image checked for alt text | All gallery images have descriptive alt text | Two images had empty alt attributes | Fail |
| 4 | Nav bar appearance in Firefox | Nav bar layout identical to Chrome version | Nav bar items stacked vertically in Firefox | Fail |
Tests 3 and 4 failed — the developer must fix the empty alt texts and investigate the Firefox CSS issue, then retest both.
A web page has the following features. Identify the accessibility problem in each case.
alt="School building from front entrance".#1a1a2e) on the yellow background, or use a darker background.:focus pseudo-class.A pupil builds a site for their class. All links work, all images load, and the nav bar appears on every page. Their teacher reports the site is very hard to use.
Create a basic test plan for a two-page school website (Home and Contact). Include at least four rows covering at least one test from each of these categories: functional, accessibility, and usability.
For each row, write: Test #, Description, Expected Result.
| Test # | Description | Expected result | Type |
|---|---|---|---|
| 1 | Click "Contact" link on Home page | Navigates to contact.html without errors | Functional |
| 2 | All images on Home page checked for alt text | Every image has a meaningful alt attribute | Accessibility |
| 3 | Home page viewed on mobile (iPhone) | Page layout adjusts and is readable on small screen | Usability |
| 4 | Home page opened in Firefox | Page appears identical to Chrome version | Browser compatibility |
Accept any valid rows. Each row should have a clear description, a testable expected result, and cover the required types. Actual results and Pass/Fail columns would be filled in after testing is carried out.
alt attribute should be on every image. Leaving it out or using alt="" on meaningful images is an accessibility failure — screen reader users get no information about the image. Decorative images may use alt="", but content images must have meaningful descriptions.The N5 exam tests web testing in three main ways: (1) "Describe one accessibility feature a developer should include" — strong answers name a specific feature (alt text, sufficient contrast, keyboard navigation) and explain why it helps. (2) "Complete the expected result column of this test plan" — write a clear, testable prediction (not just "it works" — say exactly what should happen). (3) "Explain the difference between functional and usability testing" — one sentence each: functional = features work technically; usability = easy for the target audience to use.
When asked about browser compatibility, always explain WHY it matters: different browsers use different rendering engines, so CSS and HTML may appear differently. Simply saying "test in different browsers" without explaining why is worth only 1 of a 2-mark answer.
Questions 1–3 are auto-checked. Questions 4–8 are self-marked — write your answer, then reveal the model answer to check your work.
1. What is browser compatibility testing? TYPE 1
2. Which of the following is an accessibility consideration when designing a website? TYPE 1
3. What should a test plan contain? TYPE 1
4. Describe the difference between functional testing and usability testing. Give one example of each. (2 marks) TYPE 2
Usability testing checks whether the site is easy to navigate and understand for the intended audience — whether a real user can find what they need. Example: checking that a new visitor can find the contact page within 30 seconds, or that the font size is comfortable to read (1 mark).
Key distinction: functional = technically works; usability = easy for users to use. A site can pass all functional tests and still have poor usability.
5. A website passes all functional tests — every link works, every image loads, and all forms submit correctly. However, users report that the site is very confusing to navigate. Explain how this is possible. (2 marks) TYPE 2
The developer should also carry out usability testing with members of the target audience to identify and fix navigation and layout problems.
6. A described webpage has the following features. Identify three accessibility problems. (3 marks) TYPE 2
Features: (a) a decorative banner image with no alt attribute; (b) all body text is 8pt; (c) links are shown in a slightly different shade of the same colour as the surrounding text — colour is the only visual difference.
(b) Body text at 8pt: this is far too small to read comfortably for most users. Users with low vision will be unable to read the content. Good practice is a minimum of 14–16px for body text (1 mark).
(c) Links distinguished only by colour: users who are colour blind may not be able to distinguish links from surrounding text. Links should also be underlined or visually differentiated in a way that does not rely on colour alone (1 mark).
7. Complete the expected results for these three test descriptions. (3 marks) TYPE 2
Test 1: Click the "Home" link in the navigation bar.
Test 2: View the page in Safari after designing it in Chrome.
Test 3: Check the main hero image using a screen reader.
Test 2 expected result: The page displays with the same layout, colours, and functionality in Safari as in Chrome — no broken elements or distorted CSS (1 mark).
Test 3 expected result: The screen reader announces a meaningful description of the image — the alt text describes the image content (1 mark).
Note: expected results must be specific and testable. "It works" is not a valid expected result.
8. A pupil says: "I tested my site and it works fine." Explain two reasons why this is not a sufficient approach to testing. (2 marks) TYPE 2
1. No test plan was used — without a documented test plan, some features may not have been tested at all, and there is no record of what was checked.
2. Only one browser was tested — the site may appear broken in other browsers (Firefox, Safari, Edge). Browser compatibility testing requires multiple browsers.
3. Accessibility was not tested — the pupil only tested functional features from their own perspective. Users with disabilities (e.g. screen reader users) may be unable to use the site.
4. Usability was not tested — a single user testing their own site may not represent the target audience. Features that seem obvious to the developer may be confusing for real users.
Suggested timing: 2-hour double period. First hour: notes, worked examples, now-you-try. Second hour: peer testing activity then task set Q4–Q8 individually.
Peer testing activity: Have all pupils swap their WDD project files (or describe a fictitious 2-page site) and complete a test plan on paper. Give each pupil a blank test plan template with four rows. One test must be functional, one accessibility, one usability. Swap back and compare plans. This is more memorable than reading about testing.
Live accessibility demo: If equipment allows, open wave.webaim.org on the projector and paste in any publicly accessible website URL. Show the accessibility report that comes back — errors for missing alt text, contrast failures, etc. Even a simple BBC or SQA page will have something to discuss. Alternatively, use browser DevTools → Lighthouse → Accessibility audit.
Q5 (functional pass, usability fail) is a conceptually subtle question that pupils often get wrong. Spend 5 minutes on it as a class before pupils attempt Q5 individually. Ask: "What is the difference between a technically working site and a good site?" Bridge to the idea that usability is about the user's experience, not just the code.
Q8 — the "I tested it and it's fine" answer — is a real SQA question type. Emphasise that informal testing with no plan, in one browser, from the developer's perspective is not adequate testing. Pupils should be able to give at least two distinct reasons.