Lesson 12 of 12
Structured learning draftValidate, test and publish the portfolio
Shipping is a controlled review, not merely uploading files. A release should preserve the tested source, results, known limitations and recovery path. This lesson pairs implementation with repeatable browser evidence so the learner can explain both the result and its limits.
Learning objectives
- Run a repeatable pre-release checklist.
- Test normal, boundary and failure conditions.
- Publish an evidence-backed portfolio release.
Validate, test and publish the portfolio
Validate, test and publish the portfolio: validation to cross-browser testing to deployment.
Run a repeatable pre-release checklist.
Test normal, boundary and failure conditions.
Publish an evidence-backed portfolio release.
Release checklist
- Validate HTML and inspect CSS errors.
- Test current Chromium, Firefox and WebKit-based browsers where available.
- Complete keyboard, zoom, reflow, contrast and reduced-motion checks.
- Check every internal link, form state, image and downloadable file.
- Verify HTTPS, page titles, descriptions, icon and social preview.
- Record version, date, test environment, unresolved limitations and rollback method.
Release: portfolio-v1.0
Browsers: Chrome 128; Firefox 130; Safari 18
Viewports: 320, 768, 1280 CSS px
Checks: HTML valid; keyboard pass; 400% zoom pass
Known limitation: contact form confirmation not announced
Owner and next action: Amina — add role=status before v1.1A validator checks conformance, not whether the product is understandable. Cross-browser testing should follow risk: exercise the key journey, narrow layout, form errors and media loading. Keep known limitations visible rather than silently claiming perfection.
| Evidence | Record |
|---|---|
| Source | The exact HTML and CSS tested |
| Environment | Browser, viewport and input method |
| Result | Observed behavior and test outcome |
| Limitation | Unresolved issue and next action |
Common mistakes
- Testing only the developer's primary browser.
- Publishing without a rollback copy or version.
- Treating zero validator errors as usability evidence.
Practice activity
Apply the lesson
Publish the portfolio to a preview URL and produce a release record with test evidence, known limitations and the next improvement. Submit the source files, test environment, observed result, one failure or boundary case, and a short limitation with the next corrective action.
Check your understanding
What is the strongest evidence that a release is ready?
Lesson summary
- A release is code plus evidence and ownership.
- Validate, then test actual behavior.
- Known limitations belong in the release record.
Sources and further reading
- Learn web developmentMDN Web Docs - accessed 2026-09-04
- HTML StandardWHATWG - accessed 2026-09-04
- Page Structure TutorialW3C Web Accessibility Initiative - accessed 2026-09-04
- Web Content Accessibility Guidelines 2.2W3C - accessed 2026-09-04
Course practical outcome
Design, build, test and publish a professional one-page portfolio.
Expected output: A deployed portfolio, editable source, accessibility audit and versioned release record.
Production steps
- Define audience, content and success criteria.
- Create semantic HTML and an accessible contact form.
- Build fluid CSS with Flexbox and Grid.
- Test keyboard, focus, zoom, reflow, contrast and reduced motion.
- Optimize images and measure loading behavior.
- Publish a preview and complete the release record.
Success criteria
- HTML validation has no unresolved errors.
- The complete journey works with keyboard alone.
- Content reflows at 320 CSS pixels and 400% zoom without loss.
- Text and component contrast meet the selected WCAG 2.2 target.
- Images have correct alternatives, dimensions and responsive candidates.
- Release evidence names environments, results and limitations.
Next step: Ask two representative users to complete the portfolio journey, record observations and revise the highest-impact barrier.
Personal study note