E009 Web Design Fundamentals appears under banner number ITEC 3121 and is worth 3 competency units. It is hands-on HTML, CSS and foundational JavaScript aimed at building pages that are accessible, responsive and interactive. E009 and ITEC 3121 are the same requirement under two identifiers. The three adjectives in that description are not decoration: accessibility, responsiveness and interactivity are usually where the scored aspects live, and they are what separates a page that renders from a page that passes.
Markup is structure, not appearance
The single idea that makes this course easy is the separation of concerns. HTML describes what something is: a heading, a list, a navigation region, a form control. CSS describes how it should look. JavaScript describes what happens when someone acts. Students who blur those three write markup chosen for its default appearance, which produces pages that look acceptable and fail every accessibility aspect in the rubric, because assistive technology reads the structure rather than the styling.
Accessibility is the part most students underestimate and the part most likely to be scored explicitly. It is also less mysterious than it sounds. Use headings in order and do not skip levels. Give every image a text alternative that says what the image communicates, or mark it as decorative if it communicates nothing. Label every form field so the label is programmatically connected to the control. Make sure text and background have enough contrast. Confirm that everything clickable can also be reached and operated from a keyboard. Those five habits cover a large share of what a foundations-level accessibility aspect asks for.
Responsiveness has a similar shortcut. Build the small screen layout first and let it expand, rather than designing for a wide desktop and then patching it. Fixed pixel widths are the usual culprit when a layout breaks, and a layout that never breaks is far easier to defend in a write-up than one rescued by a stack of overrides.
WGU assesses this as Competent or Not Competent, with no letter grades and no ordinary grade point average, and the 3 competency units describe the course's size within your six month term. Because the term is flat priced, a build-heavy course finished early is what makes room for the next one.
Turning aspects into a build checklist
Where E009 is assessed by a performance assessment, the scored aspects tend to divide into build requirements and explanation requirements, and both are judged. WGU requires a score of 2 in each aspect for a task to pass and scores each one alone, so a beautiful page whose write-up never explains a single decision loses the explanation aspects entirely.
Do the conversion before you write markup. Take a rubric with nine scored aspects, six about the build and three about explanation, with a written component of around 1,100 words. Build aspects need only a locator each: 70 words to name the file, the element or rule involved, and how to verify it, which is 420 in total. The three explanation aspects take the remaining 680, or roughly 226 each, which is enough for a decision, a reason and a consequence. Add a 60 word opening naming the project and the browsers you tested in, and the document lands at 1,160.
Turn those build aspects into a literal checklist before you start and tick them as you build. In a course where the deliverable is a working artifact, the most common cause of a return is not incompetence, it is that requirement six was forgotten during a long afternoon of styling.
Shape for a front-end project write-up
E009 deliverables are usually a small site or page set plus a short document. The proportions below apply to the document.
| Section | Content | Share |
|---|---|---|
| Project and environment | What was built, the file structure, and the browsers and screen sizes you tested in. | 9 percent |
| Structure choices | Which semantic elements you used for which regions, and why that markup describes the content correctly. | 18 percent |
| Styling approach | Layout technique, how the design adapts across widths, and where the breakpoints are and why there. | 18 percent |
| Interactivity | What the JavaScript does, what triggers it, and what happens if it fails or is unavailable. | 15 percent |
| Accessibility record | Each accessibility habit applied, with the specific element it applies to and how you checked it. | 20 percent |
| Validation and testing | Markup and style validation results, keyboard walkthrough, and contrast checks with the values you measured. | 12 percent |
| Close | Known limitations and the next accessibility or performance improvement you would make. | 8 percent |
Standards are the authority here, not tutorials
Front-end work has a clean and freely available source hierarchy, which makes weak citations avoidable. Element semantics and attribute behaviour belong to the published markup specification and to the major browser vendor documentation that tracks it. Accessibility claims belong to the published web accessibility guidelines rather than to a checklist someone wrote about them, because the guidelines state success criteria you can quote precisely. Style behaviour belongs to the relevant specification or to vendor documentation, and where support differs between browsers, cite a support reference and name the browsers you tested.
Evidence in this subject can be measured rather than asserted, and that is an advantage worth taking. A contrast ratio is a number. A validation result is a pass or a list of errors. A keyboard walkthrough either reaches every control or it does not. Reporting those results with their actual values turns opinion into evidence and is exactly what a scored accessibility aspect is looking for.
Screenshots deserve a rule of their own, because a front-end write-up lives on them. Capture the same page at each width you claim to support, label each capture with the width in pixels, and put them next to the paragraph that discusses that behaviour rather than in an appendix. For accessibility evidence, a capture of a contrast checker showing the measured ratio is worth more than three sentences describing your colour choices, and it takes thirty seconds to produce.
Cite in whatever style your task sets out and put the citation where the assertion actually appears. Inside code, comments should explain intent, and any snippet adapted from documentation or an example should be attributed at the point of use if your task allows adaptation at all.
Competent builds and returned ones
A Competent E009 submission validates, behaves at narrow and wide widths, is operable from a keyboard, and comes with a document that ties each decision to a requirement. It reads like someone who knows why they chose a list instead of a set of styled paragraphs.
A short pre-submission routine catches nearly everything. Run the markup through a validator and fix what it reports. Tab through the page from top to bottom without touching the mouse and confirm you can reach and operate every control. Shrink the window to a narrow width and widen it slowly, watching for the point where something overflows. Check the contrast of your smallest text against its background. Then read your rubric aspect names and confirm each one has a paragraph pointing at the thing that satisfies it. Twenty minutes of that removes most returns.
Returned work usually has one of four signatures. The page looks right and the markup is a stack of generic containers with no semantics. Accessibility is claimed rather than evidenced, with no measured contrast values and no keyboard record. The layout breaks at one width because a fixed measurement survived somewhere. Or the JavaScript works but is described only as working, with no account of what triggers it or what happens when it fails.
All four are cheap to correct, and WGU performance assessment work can be revised and resubmitted without a grade penalty, so submit once every aspect has a real answer and let the evaluator find the last gap. If your section carries an objective assessment as well, WGU objective assessments are proctored, and our boundary is fixed: we prepare with markup and style drills, code reading practice and a candid read on your preassessment result. Nobody here sits an assessment, are absent for the whole of it, and we neither ask for nor accept portal credentials.
Page renders but the rubric disagrees?
Send the E009 rubric and your files. We convert build aspects into a checklist and explanation aspects into a headed plan with word targets.
Six mistakes that cost time in E009
- Choosing elements by how they look. Markup describes meaning. Pick the element that matches the content, then style it to taste.
- Claiming accessibility without measuring it. A contrast ratio and a keyboard walkthrough are checkable facts. Assertions are not evidence.
- Designing wide first. Starting from the narrow layout removes most responsive bugs before they exist and gives you a cleaner story to write about.
- Skipping validation. A validator finds in seconds what you would spend an hour hunting, and the result is quotable evidence in your document.
- Inline styling everywhere. It works, it is unmaintainable, and it makes the styling aspect impossible to explain coherently.
- Testing in one browser at one width. The aspect usually asks about responsive behaviour, and a single screenshot cannot demonstrate it.
- Empty or duplicated alternative text. Repeating the file name or writing "image" satisfies nothing. Say what the image communicates, or mark it decorative and explain why.
- Assuming a mouse. Hover-only interactions and unreachable controls fail a keyboard walkthrough instantly, and the walkthrough is the easiest check to run before submitting.
Three questions students ask about E009
Do I need design skills to pass this course?
Can I use a framework or a template?
What is ITEC 3121 on my Degree Plan?
Where E009 sits in WGU's programs
The July 2026 catalog places this code in 2 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.