D277 Front-End Web Development is banner number ITSW 2131 and three competency units in the School of Technology. The catalog frames it as building on earlier web skills to organize a site with navigational schemes and to create reactive user interfaces with CSS, which is a precise description of the two things it grades: whether a visitor can always tell where they are, and whether the interface adapts instead of breaking. The competency it builds toward is the one every front-end role starts from, a site that holds together across pages and across screen widths. D277 and ITSW 2131 are the same three unit course.
Navigation and reactivity are the two graded ideas
A single page can be beautiful and prove nothing about front-end competence. The moment a site has five pages, questions appear that a one page project never asks. How does a visitor get from any page to any other page. How do they know which page they are on. What happens to the navigation when the screen is narrow enough that a horizontal row of links no longer fits. Those are the questions this course is built around, and they are why the deliverable is a site rather than a page.
Navigational scheme is the catalog's phrase and it means a system rather than a list of links. A system has a rule: every page carries the same navigation in the same position, the current page is marked, secondary links are grouped consistently, and no page is reachable only from one other page. An evaluator tests that by clicking, and dead ends are found in seconds.
Reactive interfaces with CSS is the second half, and reactive here means the layout responds to its container rather than to a fixed pixel width. Media queries are the obvious mechanism and the modern layout modules do more of the work: a grid that reflows because the track sizing allows it, or a flex container that wraps, needs fewer breakpoints than a float-based layout ever did. What gets scored is whether the site remains usable at a narrow width, not whether you used a particular technique.
Interaction states belong here too and students forget them. Hover, focus and active states on every interactive element, with focus visible for keyboard users, are part of an interface reacting to its user. A link that only changes on hover is invisible to somebody tabbing through the page.
Reading the aspects into a page map and a budget
WGU scores each rubric aspect separately, needs a 2 in every one, and returns a task if a single aspect falls short. For a multi-page build that means the first artifact you create is not a page, it is a grid: aspects down the side, pages across the top, and a mark in every cell where that page will satisfy that aspect. Empty rows are the aspects you have not planned for.
Then budget the writing. Suppose there are ten scored aspects and your accompanying documentation should land near 1,200 words. Ten into 1,200 is 120 each. Sort them into three kinds. The existence aspects, saying the site includes a navigation scheme or a responsive layout, need a pointer of about 60 words each naming the file and the rule. If six aspects are of that kind, they consume 360 and release 360. The design rationale aspects, asking why this navigation model or why these breakpoints, take 300 each. Three of those is 900. The last aspect is a summary or reflection and holds at 120. The total is 1,380, so trim one rationale section to 240 and you land at 1,320, still weighted correctly with three quarters of the words on reasoning.
Build the shared parts once. Header, navigation and footer identical on every page, written once and pasted, so that a change happens in one form and gets copied deliberately rather than drifting page by page.
Building the D277 site?
Send the aspects together with the brief. You get the page map, the navigation pattern, a breakpoint plan and a model of the written rationale.
A build checklist for a multi-page front end
| Area | The standard to hit | The fast check |
|---|---|---|
| Page consistency | Identical header, navigation and footer on every page, same order, same position | Open two pages side by side |
| Current page marker | The active link styled differently and marked in the markup, not only in the stylesheet | Visit each page and look at the nav |
| Link integrity | Relative paths, every page reachable, no link to a file that was renamed | Click every link from every page once |
| Layout system | One layout approach used consistently rather than three mixed together | Read the stylesheet top to bottom |
| Narrow width behavior | No horizontal scrolling, no overlapping text, navigation still usable | Drag the window to phone width |
| Interaction states | Hover, focus and active defined for links and buttons, focus visible | Tab through without touching the mouse |
| Typography and color | Readable size, contrast that passes, a limited and deliberate palette | Read a paragraph at arm's length |
Seven checks, none longer than a minute, all of them things an evaluator can do without reading your documentation. Run them yourself in the order listed before you submit.
Writing rationale, and attributing what you borrowed
Front-end rationale is a specific genre and students write it as description by default. Description says the navigation bar is at the top of every page. Rationale says the navigation sits at the top of every page because the site has seven pages in two groups, a persistent horizontal bar keeps the top-level group one click away from anywhere, and the secondary group is nested under its parent to keep the bar from wrapping on small screens. Same fact, and only the second one answers a scored aspect asking why.
Support the choices with something outside your own preference where you can. Established usability principles, published accessibility guidance and the documented behavior of the CSS features you used are all legitimate sources, cited in APA where your program requires it. A claim that a color choice improves readability is stronger with a contrast ratio attached to it than with an adjective.
Attribution is not optional because the artifact is code. Images need a source and a license. Fonts need to be linked from a service or licensed for use. Any layout snippet, icon set or animation adapted from a published example gets a comment naming where it came from. Copying a template and changing the colors is the one shortcut that reliably ends badly here, because the rationale aspects then ask you to defend decisions somebody else made.
What clears on the first try
WGU work is Competent or Not Competent with no letter grades and no ordinary grade point average, and performance assessment work that misses an aspect returns for free revision. What a return costs is calendar time inside a six month flat rate term, which is why the pre-submission checks above are worth more than another hour of polishing.
Sites that pass first time were tested somewhere other than the machine that built them. They open from the submitted folder rather than from a live server, so relative paths were correct. They were viewed at a narrow width. They were tabbed through. Their documentation names files and selectors rather than describing the site in general terms.
Returns come from a short list. A navigation scheme that is consistent on four pages and different on the fifth. A stylesheet with a stray inline style overriding it. A responsive claim with no media query or flexible layout behind it. And an aspect about accessibility answered with a sentence saying the site is accessible, which asserts the conclusion the aspect asked you to demonstrate.
Six time sinks in D277
- Styling before the pages exist. Build all the pages with real content first. A stylesheet written against one page fits one page.
- Copying the header by hand each time. It drifts. Write it once, paste it, and change it in every file at the same moment when it changes.
- Pixel widths everywhere. Fixed widths are the direct cause of horizontal scrolling on a phone, which is the single most visible responsive defect.
- Forgetting focus styles. Removing the default outline without replacing it makes the site unusable by keyboard and is a common accessibility citation.
- Testing only in one browser at one size. Two browsers and three widths takes five minutes and catches most of what gets returned.
- Describing instead of justifying. Rationale aspects ask why. A paragraph that only says what is on the page has answered a question nobody asked.
How we work on this course
D277 support runs from the page map through the final check. Send the scored aspects and the brief and you get a site structure with the navigation model chosen and justified, a breakpoint plan, a stylesheet organization that will not fight you at page four, and a model rationale document written the way WGU evaluators read. Reviews name defects and explain them rather than replacing your code, because the rationale aspects are only answerable about decisions you made. If part of your course is assessed by an objective assessment, support there is preparation only, and objective assessments are proctored: we never sit one, never assist during one, and never ask for or use your portal credentials.
A six month term at a flat rate rewards finishing. Web courses are among the fastest to close when the structure is planned in advance and among the slowest when the site is grown page by page without one.
Three questions D277 students ask
Is D277 the same course as ITSW 2131?
Do I need JavaScript for D277?
How responsive does the site actually have to be?
Where D277 sits in WGU's programs
The July 2026 catalog places this code in 3 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.