No notes. Two rounds — definitions first, then real scenarios. Answer each question before moving on.
Pick the correct protocol for each scenario.
You use HTML, CSS, and JavaScript every day for Volcanic Pantheon — but who decided what <h1> means, or how display: flex should behave? That's the job of the World Wide Web Consortium, or W3C.
The W3C is an international standards body founded by Tim Berners-Lee (who also invented the web). Its members — browser vendors, universities, companies — publish specifications that tell browsers exactly how to behave. Without W3C, Chrome and Firefox could implement things completely differently and the web would break.
WAI produces the Web Content Accessibility Guidelines (WCAG) — a set of rules for making websites usable by people with disabilities: blindness, motor impairments, colour-blindness, deafness.
<button>, <nav>, and alt attributes on imagesalt attributes on images? Can someone navigate it using only a keyboard (Tab, Enter)? These are WAI requirements. Most personal projects fail accessibility audits — but knowing the standard is what the exam asks.
i18n (shorthand: 18 letters between 'i' and 'n') is about making websites work for any language, locale, or culture.
direction: rtl for thislang attribute on <html> tells screen readers what language to pronounceW3C defines security-related browser behaviours — not just best practices, but standards that browsers must enforce:
W3C's Privacy Interest Group (PING) reviews new web features for privacy implications:
How does Google know your website is a recipe, an event, or a product listing — and show a rich result in search?
<script type="application/ld+json"> block in your <head><head>.
Match each scenario to its W3C working group (WAI, i18n, Security, Privacy, Machine-readable):
<div onclick> instead of <button>.You've used DevTools to inspect elements and debug JavaScript. But do you know every tab and what it's for? This is a named NESA dot point — you're expected to describe what DevTools does and why developers use it.
Open DevTools: F12 (Windows/Linux) or Cmd+Option+I (Mac). Here's every panel you need to know:
| Tab | What it shows | When you use it |
|---|---|---|
| Elements | The live DOM tree and CSS rules. Click any element to see its styles, margins, and box model. | Debugging layout, tweaking CSS live before committing it to code |
| Console | JavaScript errors, warnings, and console.log() output. Run JS interactively. |
Debugging JS, reading error messages, testing expressions |
| Network | Every HTTP request made by the page — URL, method, status code, headers, size, timing. Filter by type (Fetch, JS, CSS, images). | Checking API calls, seeing request/response headers, diagnosing slow loads |
| Application | localStorage, sessionStorage, cookies, IndexedDB, cache storage, service workers, manifest.json | Inspecting stored data, clearing auth tokens, checking PWA setup |
| Performance | Timeline of rendering, scripting, and painting — shows where frames are slow | Diagnosing jank (choppy animations), finding expensive operations |
| Lighthouse | Automated audit for performance, accessibility, SEO, and PWA criteria — gives scores 0–100 | Checking if a site meets WAI/accessibility standards, measuring load speed |
Everything you've learned about HTTP requests, headers, status codes, DNS, and TLS — it's all visible in the Network tab. You can see the exact URL requested, the HTTP method, the response status, all request and response headers, and how long each step took (DNS lookup, TCP connection, TLS handshake, server response, download).
Open the Network tab on any website and click a request. The Headers sub-tab shows raw HTTP. The Timing sub-tab breaks down exactly where time was spent.
authenticated: "true" key that used to control access — the same one that could be set manually to bypass your login. That's the client-side auth vulnerability you fixed by moving to Vercel Edge Middleware.
For each task, which DevTools tab would you open?
The NESA syllabus calls out three specific CSS concerns: consistency of appearance, flexibility with browsers and devices, and maintenance tools. These aren't random — they reflect real problems that professional web developers solve every day.
Imagine your brand colour (#dd6b20) is used 47 times across your stylesheet. One day the designer says "change it to #e07a30". Do you find-replace 47 lines, or change one?
CSS custom properties (aka CSS variables) solve this. You define a value once and reference it everywhere:
/* Define in :root — available everywhere */
:root {
--brand-color: #dd6b20;
--font-heading: 'Inter', sans-serif;
--spacing-md: 1.5rem;
}
/* Use anywhere */
h1 {
color: var(--brand-color);
font-family: var(--font-heading);
margin-bottom: var(--spacing-md);
}
button {
background: var(--brand-color); /* change once → updates everywhere */
}A website that looks great on a 27" monitor can be unreadable on a phone. Responsive design means the layout adapts to the screen size.
The tool is media queries — CSS rules that only apply at certain screen widths:
/* Default: mobile-first base styles */
.card-grid {
display: grid;
grid-template-columns: 1fr; /* one column on mobile */
gap: 1rem;
}
/* When screen is ≥ 768px (tablet and above) */
@media (min-width: 768px) {
.card-grid {
grid-template-columns: 1fr 1fr; /* two columns */
}
}
/* When screen is ≥ 1200px (desktop) */
@media (min-width: 1200px) {
.card-grid {
grid-template-columns: repeat(3, 1fr); /* three columns */
}
}Other responsive units you should know:
% — relative to the parent element's widthem — relative to the current element's font sizerem — relative to the root (:root) font size — more predictable than emvw / vh — percentage of the viewport width/heightclamp(min, ideal, max) — scales smoothly between a minimum and maximum valuePlain CSS has no variables (before custom properties), no nesting, no loops, and no way to split a large stylesheet into smaller files. SASS (Syntactically Awesome Stylesheets) is a CSS preprocessor — you write SASS, it compiles to plain CSS that browsers understand.
.nav { background: #1a202c; }
.nav a { color: white; }
.nav a:hover { color: #dd6b20; }
.nav-mobile { display: none; }
@media (max-width: 640px) {
.nav-mobile { display: block; }
}$brand: #dd6b20;
$dark: #1a202c;
.nav {
background: $dark;
a {
color: white;
&:hover { color: $brand; }
}
&-mobile {
display: none;
@media (max-width: 640px) {
display: block;
}
}
}Key SASS features for the exam:
$brand-color: #dd6b20 — like CSS custom properties but processed at compile time_buttons.scss, _nav.scss, etc., then @import them — keeps large projects manageableThe syllabus groups these as: "CSS — consistency of appearance, flexibility with browsers/devices, maintenance tools." Map your knowledge directly: consistency = CSS variables, flexibility = media queries + responsive units, maintenance = SASS/preprocessors + file organisation.
Almost no production website is built from scratch. Developers stand on the shoulders of thousands of open-source packages — and the NESA syllabus specifically calls out four types: frameworks, template engines, predesigned CSS classes, and open-source software.
A library solves one specific problem. You choose when and where to use it. Your code is in charge — you call the library when you need it.
A framework provides the overall structure. You fill in the blanks it defines. The framework is in charge — it calls your code at the right moment (the "Hollywood Principle": don't call us, we'll call you).
A template engine lets a server generate HTML dynamically — mixing a fixed HTML structure with live data from a database.
Without a template engine, you'd have to concatenate strings in code to build HTML responses — which is messy and vulnerable to XSS. Template engines handle escaping automatically.
<!-- Jinja2 template (Python/Django) -->
<h1>Welcome, {{ user.name }}!</h1>
<ul>
{% for post in posts %}
<li>{{ post.title }} — posted {{ post.date }}</li>
{% endfor %}
</ul>The server fills in {{ user.name }} and loops over posts, then sends complete HTML to the browser. The browser never sees the template syntax — just finished HTML.
Common template engines: Jinja2 (Python), Handlebars (JavaScript), EJS (Node.js), Blade (PHP/Laravel).
Instead of writing every CSS rule yourself, you can use a library of pre-made classes and just apply them in your HTML:
<!-- Bootstrap: semantic class names that apply styles -->
<button class="btn btn-primary btn-lg">Submit</button>
<div class="container mt-4 p-3 bg-light rounded">...</div>
<!-- Tailwind: utility classes (one class = one CSS rule) -->
<button class="bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700">Submit</button>
<div class="max-w-4xl mx-auto mt-4 p-3 bg-gray-100 rounded">...</div>| Feature | Bootstrap | Tailwind CSS |
|---|---|---|
| Approach | Pre-built components (modals, navbars, cards) | Utility-first (build your own components) |
| Class names | Semantic (btn-primary) | Descriptive (bg-blue-600 text-white) |
| Customisation | Override defaults | Highly configurable design system |
| File size | Larger (full component library) | Small (PurgeCSS removes unused classes) |
| Best for | Quick prototypes, admin dashboards | Custom designs without leaving HTML |
Almost every library and framework above is open-source — the source code is publicly available for anyone to use, study, modify, and distribute.
Open-source powers the entire web stack — Node.js, Python, Linux, Nginx, PostgreSQL, Git — all open-source. The trade-off is that maintaining these projects relies on volunteers and sponsorships.
When you run npm install, you're downloading code written by strangers onto your machine. In Lesson 10 you saw that attackers target npm packages to compromise thousands of projects at once. This is the supply chain risk inherent in open-source dependency ecosystems.
Mitigations: pin dependency versions, audit with npm audit, prefer well-maintained packages with many contributors, and never blindly upgrade all packages before a production release.
For each item, identify whether it is a library, framework, template engine, or predesigned CSS classes:
Not every website is built by a developer. A business owner needs to update their product descriptions, add new blog posts, or change their opening hours — without touching code. That's what a CMS is for.
A CMS separates content (text, images, data) from presentation (templates, CSS). Non-developers edit content through a visual dashboard; the CMS handles rendering it to HTML.
| CMS | Type | Who uses it | Notes |
|---|---|---|---|
| WordPress | Traditional (self-hosted) | Blogs, business sites, news | Powers ~40% of the web. Plugin ecosystem. Requires PHP server. |
| Wix / Squarespace | Hosted drag-and-drop | Small businesses, portfolios | No coding needed. Less flexible. Monthly fee. |
| Shopify | E-commerce CMS | Online stores | Manages products, checkout, inventory. |
| Contentful / Sanity | Headless CMS | Developers building custom frontends | API-first — delivers content as JSON to any frontend (React, mobile). |
Traditional CMS (WordPress): the CMS controls both the content database and the HTML rendering. Tightly coupled.
Headless CMS (Contentful, Sanity): the CMS manages content and exposes it via API. Your React app (or any frontend) fetches the content and decides how to display it. More flexible, but requires developer work.
NESA expects you to evaluate CMS options — not just list them. That means applying criteria to a specific scenario and justifying a recommendation. Here are the six criteria to use:
| Criterion | What to assess | Why it matters |
|---|---|---|
| Cost | Free, subscription, or enterprise pricing? Hosting included? | Determines viability for the client's budget |
| Technical skill required | Can a non-developer use it? Does setup require a developer? | Determines who can actually maintain the site long-term |
| Customisability | Can the design be fully customised? Are there template limits? | Determines whether the client's design requirements can be met |
| Scalability | Can it handle growth in users, content, or traffic? | Avoids needing a full rebuild when the business grows |
| Vendor lock-in | Can you export content and migrate away? Is data portable? | Protects the client if pricing changes or the vendor closes |
| Open-source vs proprietary | Is the source code available? Can you self-host? | Affects long-term control, security auditing, and cost |
Scenario: A local restaurant wants a website to display their menu and accept online reservations. They have no developer on staff, a modest budget, and want to update the menu themselves whenever dishes change.
Evaluate two CMS options and justify a recommendation.
Option A — WordPress
Option B — Squarespace
Recommendation: Squarespace is the better choice for this client. The restaurant owner has no developer on staff, so the zero-setup, non-technical interface is the decisive factor. While WordPress is more flexible and cheaper long-term, it requires developer involvement for setup and ongoing maintenance — a hidden cost the client cannot meet. The scalability and lock-in trade-offs are acceptable given the modest, stable requirements of a local restaurant. If growth or advanced features become necessary, a migration could be considered at that point.
A 1-second delay in page load time reduces conversions by 7% (Amazon research). Performance is not optional — it's a user experience and business concern.
Removing whitespace, comments, and shortening variable names in JS/CSS files. app.js (47 KB) becomes app.min.js (18 KB). Tools: Terser (JS), cssnano (CSS), or bundlers like Vite/Webpack that minify automatically on build.
A CDN stores copies of your static files (HTML, CSS, JS, images) on servers around the world. When a user requests your site, they're served from the closest node — reducing latency from hundreds of milliseconds to single digits.
By default, browsers download all images on a page immediately — even ones far below the fold that the user may never scroll to. Lazy loading defers loading until an image is about to enter the viewport.
<!-- Native browser lazy loading — one attribute -->
<img src="shrine-photo.jpg" alt="Volcanic Pantheon shrine" loading="lazy">The Cache-Control HTTP response header tells the browser how long to store a resource locally before fetching it again from the server.
Cache-Control: max-age=31536000, immutableThis tells the browser: "keep this file for one year, and it will never change." Your CSS and JS files (which have hashed filenames after build) can be cached forever — because if they change, they get a new filename.
srcset to serve different sizes to different screen resolutionsYou already use Git and GitHub for Volcanic Pantheon — but you're the only developer. Version control in teams works differently, and the NESA syllabus expects you to understand collaborative practices.
In a team, everyone working on main simultaneously causes chaos. Instead:
git checkout -b feature/login-pagemainKey benefits:
A client runs a bakery. They want a website where they can update their menu, post weekly specials, and take online orders. They have no coding knowledge. They get 2,000 visitors a day from across Australia.
For each decision below, choose an option and justify it:
lang attribute on <html>.--brand-color). Define once, use everywhere. Change one value to update consistently across whole site.@media (min-width: 768px) { ... } — CSS rules that only apply at certain screen widths. Foundation of responsive design.loading="lazy" on images — defer download until needed.