D276 Web Development Foundations carries banner number ITSW 2120 and is worth three competency units in the School of Technology. The catalog describes it as web design and development using HTML and CSS delivered through the zyBooks learning platform, which makes it the first course in the technology sequence where you hand in something a person can look at. What it builds toward is structural literacy: markup that means what it says and styling that is separated from it, because every later web course, from front-end work to back-end templating, assumes that separation is already instinct. D276 and ITSW 2120 are two names for this same three unit course.
Markup that means something is the whole competency
Any student can produce a page that looks acceptable in a browser. Browsers are forgiving, they repair broken nesting silently, and a wall of div elements with classes named box1 and box2 renders exactly like a page built properly. That forgiveness is the trap in this course, because the scored work is not whether the page renders. It is whether the document structure communicates meaning without the stylesheet attached.
Semantic elements are the visible test of that. A header, a nav, a main, a set of sections and articles, a footer: these describe what a region is, and a screen reader, a search crawler and an evaluator all read that description. Heading levels carry the same weight. An h1 followed by an h3 is not a style choice, it is a hole in the outline, and it is one of the fastest things for an evaluator to spot because it can be checked without reading a word of your content.
On the CSS side the competency is separation and reuse. Inline style attributes scattered through the markup will render, and they demonstrate the opposite of what the course teaches. The scored work wants a stylesheet, selectors chosen deliberately, and a specificity story you can explain when two rules collide. Students who learn the cascade properly here stop fighting their own stylesheets forever after.
The zyBooks environment shapes how the material arrives, with reading interleaved with small participation activities and challenge exercises. Those activities are practice, not the deliverable. Finishing every interactive block is a good signal that you read the chapter and a poor predictor of whether your submitted site meets its aspects.
Converting scored aspects into a build order and a word budget
WGU judges each rubric aspect on its own, a score of 2 in every aspect is what passes a task, and nothing averages. For a build course that means your aspect list is a construction checklist rather than an essay outline, and the correct move is to translate every scored row into a specific file, element or rule you can point at.
Work an example. Suppose your rubric shows nine scored aspects across the site and any accompanying documentation, and you expect to write roughly 900 words of explanation alongside the code. Nine into 900 is 100 words per aspect, which sounds thin until you sort the rows. Four of those aspects are almost certainly build requirements, the kind that say the site includes a functioning navigation scheme, and a build requirement needs only two or three sentences of pointer text saying where it lives, so call those 50 words each. That releases 200 words. The aspects that ask why, such as a justification of the layout approach or an explanation of how the styling supports usability, take 250 each. Two of those consume the 200 you released plus their share, and the budget still lands at 900 with the reasoning sections three times the size of the pointer sections.
Then set the build order from dependency rather than from the rubric order. Content and structure first, then the stylesheet, then navigation, then responsive adjustments, then accessibility passes. Building in rubric order forces you to restyle things twice.
Building the D276 site now?
Send the aspects and the brief. You get a build order, a markup skeleton keyed to each scored row, and notes on what the evaluator will check first.
Anatomy of a foundations web deliverable
Web deliverables get checked in two passes: a look at the rendered result, then a read of the source. The table maps what each layer needs to survive both.
| Layer | What has to be true | How an evaluator verifies it |
|---|---|---|
| Document skeleton | Doctype, language attribute, character set, viewport meta, descriptive title per page | Reads the first ten lines of source |
| Semantic regions | Header, nav, main and footer present and used once each per page as appropriate | Searches the source for the element names |
| Heading outline | One h1 per page, no skipped levels, headings describing content rather than sizing it | Scans headings top to bottom |
| External stylesheet | One linked stylesheet, no inline style attributes, selectors that read as intent | Opens the CSS file and greps the markup for style equals |
| Navigation | Every page reachable, links relative and working from any page, current page indicated | Clicks every link in both directions |
| Images and media | Alt text that describes function, sensible file sizes, dimensions that do not distort | Turns images off or reads the alt attributes |
| Accessibility basics | Contrast that passes, labels tied to inputs, focus visible on keyboard navigation | Tabs through the page without a mouse |
The last row is the one students discover late. Tabbing through your own site once, before submission, catches more defects in ninety seconds than any amount of rereading the rubric.
Validation, attribution and the evidence a web course accepts
In a writing course your evidence is sources. Here it is verification, and the strongest verification is machine checkable. Run your markup and your stylesheet through a validator and fix what it reports before submission. An evaluator who finds unclosed tags has been handed a reason to look harder at everything else, and a clean validation report costs you ten minutes.
Attribution still applies even though the artifact is code. Images you did not create need a source and a license that permits your use, and free stock sites usually state both on the download page. Fonts loaded from a hosted service should be linked rather than copied. If any part of your layout follows a published technique or a framework example, say so in a comment or in your documentation rather than presenting it as original, and never paste in a template and rename the classes. Where your program requires APA in the written portion, the same rules apply as in any other course: in-text citations and reference entries that agree with each other.
Comments in the code are a legitimate evidence channel and an underused one. A short comment above a rule explaining why a particular selector was needed reads to an evaluator as understanding, and it takes one line.
What earns Competent here and what comes back
WGU records work as Competent or Not Competent, with no letter grades and no ordinary grade point average, and performance assessment work can be revised and resubmitted without penalty if an aspect is missed. The cost of a return is the queue, not your record, which is exactly why the cheap pre-submission checks matter so much in a build course.
Submissions that clear the first time tend to be honest about scope. They build the pages the brief asked for, they do not add a half-finished contact form that nobody requested, and every scored aspect has an obvious home. They also work from a fresh browser: opened from the actual file path, on a machine that has never seen the project, with no cached stylesheet doing invisible work.
Returns concentrate in three places. Links that work locally and break in the submitted folder because a path was absolute. Styling applied inline in a few stubborn spots after the stylesheet was written. And an aspect about responsiveness or accessibility answered by claiming the site is responsive and accessible without pointing at the media query or the markup that makes it so.
Six mistakes that cost time in D276
- Designing in the browser before writing the content. Layout decisions made without real content collapse when real content arrives, and you rebuild twice.
- Using divs where an element already exists. A nav wrapped in a div with a class called nav is the exact pattern the course teaches you to stop.
- Choosing heading levels by size. Headings define an outline. Size is a stylesheet decision and belongs in the stylesheet.
- Absolute file paths. A link that starts with a drive letter works on your desktop and nowhere else, and it turns a working site into a broken one at submission.
- Alt text that repeats the file name. Alt describes what the image conveys. An empty alt attribute is correct for a purely decorative image and better than a wrong description.
- Confusing zyBooks completion with course completion. Finishing every participation activity is preparation. The scored deliverable is separate, and it is what gets evaluated.
How we work on this course
Support for D276 starts at the plan and stays with the build. Send the scored aspects and the brief and you get a build order, a commented markup skeleton that shows where each aspect will be satisfied, a review pass over your own code that names defects rather than silently fixing them, and a model of the written explanation in the register WGU evaluators expect. Where any part of your course is assessed by an objective assessment, we prepare only: concept notes, practice questions and a direct read on whether the preassessment says go now or study more. Objective assessments at WGU are proctored, we never sit one, never assist during one, and never ask for or use your portal login.
Three competency units closed early in a six month flat rate term is time you keep for whatever course turns out to be hard. Web foundations is usually one of the faster wins available in the technology plan when it is planned rather than improvised.
Three questions D276 students ask
Is D276 the same course as ITSW 2120?
Do I need to finish all the zyBooks activities to pass?
Can I use Bootstrap or another framework for the site?
Where D276 sits in WGU's programs
The July 2026 catalog places this code in 7 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.