Validate and test a website

Outcome

You will create and complete a test report for one coded website. You will validate the HTML, review CSS diagnostics in VS Code, test the browser result in named conditions, repair confirmed issues, and retest the same evidence path.

Why this matters

A page that looks correct in one browser state can still contain invalid source, broken links, inaccessible keyboard behavior, missing image text, or layout failures at another size. A written test report separates what you expected from what you observed.

What you will practice

Distinguish source validation, browser testing, accessibility checks, and content review.
Write test cases with a condition, action, expected result, actual result, and status.
Use the HTML checker and VS Code CSS diagnostics without treating every tool message as the same kind of defect.
Test links, images, headings, keyboard behavior, narrow layout, zoom, and browser history.
Retest a confirmed issue and run related regression checks after a repair.
Use Git to preserve the unchanged baseline, focused repairs, and final test evidence.

What is new and what is reused

New: Quality assurance, validation, test case, expected result, actual result, evidence, reproduction steps, regression check, and report status.
Reused: HTML, CSS, links, images, alternative text, semantic headings, developer tools, keyboard focus, responsive layouts, media queries, and 200% zoom testing.

Starting point

Before you start

Your completed page-assets project, or another coded profile project with a clean final Git state.
A project with index.html, styles.css, and every local asset stored inside the project folder.
A current browser, VS Code, Git, a GitHub account, and internet access for the Nu Html Checker.

Current state: The website appears complete in its existing project. The separate quality-profile folder, repository, baseline commit, and test report do not exist yet.
First action: Create an empty folder named quality-profile. Copy the source project's visible files and folders into it without copying .git, then open quality-profile in VS Code.
First checkpoint: quality-profile has its own private repository with an unchanged baseline commit, and test-report.md is ready for the test plan.
Help trigger: Use the recovery note or ask for help if a source-check message is unclear, a failure cannot be reproduced, the test itself changes the source, or a repair causes a previously passing check to fail.

Required result

You have completed the lesson when quality-profile has:

an unchanged starting-state copy before any repair;
a separate Git repository on main with its own private GitHub repository connected as origin;
a baseline commit, focused commits for any source repairs, and a final test-report commit;
test-report.md with environment, scope, test cases, actual evidence, status, and issue records;
an HTML validation result in which every reported message is fixed or classified with a reason;
a CSS diagnostic result from VS Code in which every reported message is fixed or classified with a reason;
passing tests for page load, headings, links, local images, keyboard use, focus, browser history, about 320px width, and 200% zoom;
no unintended horizontal page scroll, clipped focus, distorted image, or pointer-only required action;
a retest record for every repaired issue;
related regression checks after each repair; and
a final summary that states what was tested, what passed, any accepted limitation, and what remains outside the test scope.

Create the independent quality project

Create an empty folder named quality-profile inside your Level 1 projects folder.
Copy the visible project files and asset folders from the completed source project into quality-profile.
Do not copy the hidden .git folder. The source repository and its origin remote must remain separate.
Open quality-profile as the workspace root in VS Code.
Open index.html and confirm that the page matches the completed source project.
Create test-report.md in the project root.

From quality-profile, run:

git init -b main
git add .
git diff --staged --stat
git commit -m "Create quality profile baseline"

Create an empty private GitHub repository named quality-profile. Do not add a README, .gitignore, or license on GitHub. Copy its HTTPS URL, then connect and push the project:

git remote add origin https://github.com/YOUR-USERNAME/quality-profile.git
git push -u origin main

Run git remote -v. Confirm that origin points to quality-profile, not the source project. Reload GitHub and confirm that the unchanged baseline commit is visible.

Separate validation from testing

HTML validation compares the saved HTML source with the rules checked by the Nu Html Checker. It can find missing closing tags, invalid nesting, prohibited attributes, and similar source problems.

CSS diagnostics are the errors and warnings that VS Code reports while it reads styles.css. They can find malformed rules, unknown properties, and some invalid values. They are editor feedback, not proof that the CSS works in every browser or layout.

Testing performs an action in a named condition and compares the actual result with an expected result. It can find a link that targets the wrong section, a focus indicator that is clipped, or a layout that fails at a narrow width even when the source is valid.

Accessibility evaluation combines automated checks, source inspection, manual interaction, and user evidence. The preliminary keyboard, heading, image, zoom, and structure checks in this lesson do not prove complete accessibility conformance.

Content review checks whether titles, labels, instructions, links, and descriptions are accurate, useful, and safe to publish.

No one tool covers all four areas.

Quality-assurance loop

A useful test compares an expected result with recorded evidence

Follow the main path downward. At the decision, follow Pass or Issue.

Status comes after evidence. A repair is complete only when the original test passes and related working behavior still passes.

Create the test report

Add this structure to test-report.md:

# Quality report: profile website

## Environment

- Project: quality-profile
- Browser and version:
- Operating system:
- Test date:
- Wide viewport:
- Narrow viewport: about 320 CSS pixels
- Zoom test: 200%

## Scope

Included: index.html, styles.css, local links, local images, keyboard behavior, responsive layout, and visible content.

Outside this report: server behavior, real network performance, assistive-technology user testing, and browsers not listed above.

## Test cases

| ID | Condition and action | Expected result | Actual result | Status | Evidence or next action |
| --- | --- | --- | --- | --- | --- |
| VAL-01 | Validate index.html | No unresolved HTML errors | Not run | Not run | Upload the saved file |
| CSS-01 | Review styles.css in VS Code Problems | No unresolved CSS author errors | Not run | Not run | Save the file and open Problems |
| FUN-01 | Open index.html | Page loads with CSS and local assets | Not run | Not run | Open from the project folder |
| NAV-01 | Follow every local navigation link | Each link reaches its named target | Not run | Not run | Test in source order |
| IMG-01 | Load and block each meaningful image | Image loads; alternative text fits the context | Not run | Not run | Inspect img source and alt |
| KEY-01 | Use Tab, Shift+Tab, and Enter | Every link is reachable, visible, ordered, and usable | Not run | Not run | Put the pointer aside |
| RES-01 | Test at about 320px width | No unintended horizontal scroll or clipped content | Not run | Not run | Record viewport width |
| ZOOM-01 | Test at 200% zoom | Content reflows without overlap or loss | Not run | Not run | Record visible result |

## Issues and retests

Add one subsection per confirmed issue.

## Final summary

Complete after all required tests and retests.

Use these status values only:

Not run: no current evidence;
Pass: actual result matches expected;
Issue: actual result does not match expected;
Blocked: the named condition cannot be tested and the report states why; and
Accepted limitation: a verified tool or scope limit remains and the report explains its consequence.

Do not use Pass because the page looks plausible. Record the actual result first.

Checkpoint: The test plan is explicit

What now works: test-report.md identifies the environment, included and excluded scope, eight required test cases, expected results, and stable status labels.
Files changed: test-report.md
What remains: Validate the HTML, review CSS diagnostics, classify every message, then perform browser and accessibility checks.
Next action: Open the Nu Html Checker and select the input option for a local file.
If it does not work: If a test row feels vague, add the viewport, input method, target element, action, and observable result needed to repeat it.

Validate the HTML source

Use the Nu Html Checker to inspect the saved index.html file.

Save index.html in VS Code.
Open the Nu Html Checker.
In Checker Input, choose the local file-upload option.
Select quality-profile/index.html.
Enable source and outline when those options are available.
Start the check.
Record the number and type of messages in VAL-01 before changing the source.

The checker can report:

Error: Source that conflicts with the checked HTML rules and needs investigation.
Warning: A condition that can be risky or unclear but needs context before a change.
Information: Additional explanation about the parsed document.

Start with the first error in source order. Read the message, line, and nearby source. One missing tag can create several later messages, so fix one cause and validate again before editing every reported line.

Record an HTML issue

Use this pattern when a message identifies an author error:

### ISSUE-01: Unclosed article element

- Test: VAL-01
- Source: index.html, near the second project entry
- Reproduction: Upload the saved index.html to the Nu Html Checker.
- Expected: Each article element closes before the next sibling begins.
- Actual: The checker reports an unclosed article and later nesting errors.
- Change: Add the missing closing article tag.
- Retest: Upload the saved file again and record the new result.
- Regression checks: FUN-01, NAV-01, RES-01

Do not add a random closing tag until the element hierarchy shows where it belongs.

Inspect the heading outline

If the checker provides an outline, compare it with the visible page:

one H1 identifies the page;
each H2 identifies a major section;
each H3 belongs inside an H2 section; and
the outline order matches the source and reading order.

An outline check does not replace reading the headings. A syntactically ordered heading can still use vague text.

Complete VAL-01

Repeat validation after each HTML repair. Set VAL-01 to Pass when no unresolved HTML error remains. If a message appears to be a checker limitation, record the exact message and verify the syntax against a current specification or official reference before using Accepted limitation.

Do not silence a message by deleting valid content or accessibility information without understanding the consequence.

Review CSS diagnostics in VS Code

VS Code checks CSS while you work. Use the Problems panel to review the saved styles.css file in the same editor where you wrote it.

Open quality-profile/styles.css in VS Code and save the file.
Confirm that the language mode in the status bar is CSS.
Open View → Problems.
Select each message for styles.css and read the complete rule around the named line.
Record the number and type of CSS errors and warnings in CSS-01 before editing the source.
If the panel reports no CSS message, record 0 errors and 0 warnings as the actual result.

VS Code can report a message for syntax that it does not understand. A message is not automatically an author defect, and an empty Problems panel is not proof that the layout works.

Classify each message as one of these:

Author error: A misspelled property, malformed value, missing brace, or invalid rule. Fix and retest.
Context warning: Valid source that needs a project decision. Record the decision.
Verified editor limitation: Current standard syntax that VS Code does not understand. Record the message and the official reference used to verify the syntax.
Unresolved: Evidence is not sufficient. Keep status Issue or Blocked and ask for help.

Do not replace current valid syntax only to clear a diagnostic that comes from an editor limitation.

Complete CSS-01

Set CSS-01 to Pass when no unresolved CSS author error remains. Use Accepted limitation only when the report contains the exact diagnostic, the checked syntax, and the official source that confirms the current syntax.

Assistance 3 — Investigate one source-check message at a time

For each message:

Copy the exact message into the report.
Open the named line and read the complete rule or element.
State one hypothesis about the cause.
Make the smallest source correction that tests the hypothesis.
For HTML, save and rerun the checker. For CSS, save and review the Problems panel again.
Compare the new message list with the old list.

If the message remains and the browser accepts the syntax, do not assume either side is correct. Check a current official language reference or ask for help.

Checkpoint: Source messages are resolved or classified

What now works: VAL-01 and CSS-01 record the check conditions, original messages, repairs, retests, and any evidence-backed tool limitation.
Files changed: index.html, styles.css, test-report.md
What remains: Run behavior, accessibility, responsive, zoom, and content tests in the browser.
Next action: Open the saved index.html and complete FUN-01 before testing individual links.
If it does not work: If one repair created more messages, undo only that repair, save, and repeat the same source check to restore the last confirmed state.

Test the complete page load

Open quality-profile/index.html in the browser.

For FUN-01, record:

whether the stylesheet loads;
whether each local raster and SVG asset loads;
whether the page title appears in the browser tab;
whether the visible content matches the intended profile; and
whether the browser console reports a missing local resource.

If an asset fails, record the exact requested path and status before changing a filename. A path can fail because of spelling, letter case, folder location, or a stale reference.

Test links and browser history

For NAV-01, start at the address bar and use the keyboard:

Press Tab until the first page link receives focus.
Record the visible link label and destination.
Press Enter.
Confirm that the browser reaches the named section or resource.
Use the browser Back button or shortcut.
Repeat for every local navigation, project, and contact link.

Check that:

link text predicts the destination;
same-page fragment links target an existing unique id;
internal links stay in the same tab unless a stated need requires another behavior;
mail links use the intended reserved address; and
focus remains visible after you return.

Test images and text alternatives

For IMG-01, inspect each img element and its visible context.

For a meaningful image:

the file loads from the expected local path;
alt describes its purpose in context;
a caption remains visible when the design requires one;
width and height preserve the intrinsic aspect ratio; and
CSS does not distort or overflow the image.

For a decorative image, confirm that alt="" is intentional and that nearby content does not depend on the image.

Temporarily change one image src in developer tools so the request fails. Do not save this change to index.html. Confirm that the remaining text still communicates the page purpose and the alternative text is appropriate for the missing image.

Test keyboard order and focus

For KEY-01, put the pointer aside.

Start in the browser address bar.
Press Tab through every interactive element.
Press Shift + Tab to move backward.
Use Enter to activate links.
Confirm that focus never becomes trapped.

Record whether:

every interactive element is reachable;
focus follows the content order;
the focused element has a visible non-color-only indicator;
no noninteractive image or heading creates an unexpected tab stop; and
required information is not available only on pointer hover.

An automated checker cannot replace this input test.

Test narrow width and zoom separately

Viewport width and browser zoom create related but different conditions. Record both.

RES-01: about 320 CSS pixels

Use responsive design mode or a narrow browser window. Record the actual viewport width.

Check that:

the page has no unintended horizontal scrollbar;
navigation wraps or changes layout without hiding links;
headings and long link text wrap;
images stay inside their containing blocks;
project entries preserve their source order; and
focus indicators are not clipped at the viewport edge.

ZOOM-01: 200% browser zoom

Return to a normal desktop viewport and set browser zoom to 200%.

Check that:

text reflows instead of overlapping;
no content or control disappears;
links and focus remain usable;
the reading order stays logical; and
the page does not require two-direction scrolling to read ordinary content.

Do not use CSS zoom or operating-system magnification as a substitute for the named browser-zoom condition in this test.

Checkpoint: The browser result has recorded evidence

What now works: FUN-01, NAV-01, IMG-01, KEY-01, RES-01, and ZOOM-01 contain actual results, status, evidence, and any linked issue record.
Files changed: test-report.md
What remains: Repair confirmed issues, retest the same conditions, run regression checks, and write the final summary.
Next action: Choose the first Issue row and reproduce it once without changing the source.
If it does not work: If a failure cannot be repeated, keep the original observation, record the second result, and do not claim a repair that you cannot verify.

Repair and retest confirmed issues

Work on one confirmed issue at a time:

Reproduce the issue in the recorded condition.
State one likely cause.
Change the smallest relevant source area.
Save the file.
Repeat the original test with the same condition and action.
Record the new actual result.
Run the related regression checks named in the issue record.
Inspect, commit, and push the repaired source plus its updated test evidence with a focused message such as Fix narrow profile overflow.

Example: if you repair a navigation selector, retest keyboard focus, narrow wrapping, and every link that uses the shared selector. Do not mark the issue resolved because one screenshot looks different.

Final report summary

Complete the final section with this structure:

## Final summary

- Source checks: [HTML validation result and CSS diagnostic result]
- Browser behavior: [tests passed and named environment]
- Accessibility checks: [keyboard, focus, headings, images, zoom]
- Responsive checks: [narrow width and any wider comparison]
- Repairs: [issue IDs repaired and retested]
- Accepted limitations: [none, or evidence-backed limitations]
- Outside scope: [tests not performed]
- Next action: [one concrete follow-up, or no required follow-up]

State none where no accepted limitation remains. Do not omit the field.

Record the completed quality evidence

After every required test and retest passes or has an evidence-backed status, run:

git status
git diff
git add test-report.md
git diff --staged
git commit -m "Document website test results"
git push

If an uncommitted source repair remains, stage that file with test-report.md only when the report contains its passing retest and related regression evidence. Reload GitHub and confirm that the final report commit appears after the baseline and any focused repair commits.

Self-check

Complete these checks against the required result.

Open test-report.md and confirm that the environment, actual browser version, date, viewport conditions, scope, and exclusions are complete.
Confirm that VAL-01 records the final HTML result and every original error or warning is fixed or classified with evidence.
Confirm that CSS-01 records the final VS Code result and distinguishes author errors from verified editor limitations.
Open the page and confirm that CSS and every local asset load without an unresolved missing-resource error.
Follow every local link with the keyboard and confirm that labels, targets, history, order, and focus work.
Inspect every image and confirm that its source, dimensions, aspect ratio, alternative text, and visible context are correct.
Test at about 320 CSS pixels and confirm that no content, image, link, or focus indicator is clipped or causes unintended horizontal scrolling.
Test at 200% browser zoom and confirm that content reflows without overlap, loss, or two-direction reading scroll.
Open every issue record and confirm that it contains reproduction, expected result, actual result, change, retest, and regression evidence.
Confirm that the final summary names the completed test scope, accepted limitations, excluded scope, and next action.
Explain why valid HTML and CSS do not prove that links, keyboard behavior, accessibility, content, or responsive layout work.
Run git log --oneline and identify the baseline, every focused repair commit, and the final test-report commit.
Run git status and confirm that the working tree is clean. Confirm that the private GitHub repository contains the latest commit.

Quality is a set of claims with evidence

HTML validation proves only that the checked source matches the rules understood by the selected checker. CSS diagnostics prove only that VS Code found no unresolved source problem that it understands. A manual test proves only the named behavior in the recorded environment and condition. A preliminary accessibility check can reveal barriers but cannot prove complete accessibility.

The report is useful because it keeps each claim proportional to its evidence. It also gives another person enough context to repeat the test and compare results.

Optional quality investigations

The required lesson is complete before these investigations. Choose one route that broadens the evidence without changing the required finish line.

Compare two browsers

Repeat FUN-01, NAV-01, KEY-01, RES-01, and ZOOM-01 in a second browser engine. Add the browser version and keep the original results. Record only differences you can reproduce.

Test the CMS checkpoint

Restore cms-seo-checkpoint.zip and adapt the same report structure to the visitor view. Keep CMS administration behavior separate from public page behavior and do not upload a private Playground URL to a public validator.

Add a reduced-motion test

If the page contains motion, enable the operating system’s reduced-motion preference and reload. Confirm that no information or required state depends on motion. If the page has no motion, record that the condition is not applicable and why.

Run an automated accessibility scan

Use a teacher-approved browser tool. Record the tool and version, each finding, manual confirmation, and false-positive decision. Do not replace the required keyboard and zoom tests with the scan.

Optional references

Nu Html Checker checks HTML source and can show source and outline information.
CSS in Visual Studio Code explains the built-in CSS language support and validation settings.
W3C CSS Validation Service provides an optional second CSS check.
W3C Easy Checks provides preliminary accessibility checks for page titles, headings, images, keyboard focus, and zoom.

Next step or safe stopping point

The required lesson is complete when the report contains evidence for every required test, every confirmed issue has a same-condition retest and regression checks, and the final summary states the limits of the evidence.

Continue to Document your work to turn project purpose, structure, decisions, setup, tests, and known limits into documentation another person can use.

If you stop here, leave yourself this resume note at the top of test-report.md: Testing is complete. Next, preserve this report and write project documentation from verified facts only.