CIW Web Design common mistakes
CIW Web Design · Understand the traps and how to avoid them.
Assuming that using a <div> with CSS positioning makes a layout 'valid' while ignoring that the underlying document structure no longer reflects content hierarchy, so the answer chosen is the visually equivalent one rather than the semantically structured one.
Candidates study CSS layout mechanics (floats, positioning, flexbox) intensively and treat visual equivalence as the goal, forgetting that CIW items test whether the markup conveys meaning and reading order independent of presentation.
What to do instead
For any layout question, first ask what the content structure is (headings, lists, sections, reading order), then evaluate whether the proposed markup preserves that structure without CSS. Practise rewriting table-based or absolutely-positioned layouts into semantic markup and note which elements carry meaning versus decoration.
Selecting the answer that describes a deprecated presentational HTML attribute or element (for example align, bgcolor, font, center) as the correct way to achieve a visual effect, rather than the CSS-based approach.
Older tutorials, legacy code samples, and inherited habits make presentational HTML feel familiar and 'simple', and candidates recognise the effect being described without checking whether the technique is current practice.
What to do instead
Maintain a short list of obsolete presentational elements and attributes and mentally flag them as distractors whenever they appear. For every styling scenario, confirm the answer separates structure (HTML) from presentation (CSS) and uses selectors, properties, or an external stylesheet.
Confusing the roles of client-side and server-side technologies, for example choosing JavaScript to query a database or choosing a server-side language to validate input in the browser before submission.
The exam describes multi-tier architecture in prose rather than code, and candidates who have built small sites often blur the boundary because their own projects used one language for everything.
What to do instead
Draw the three tiers (presentation/browser, business logic/application server, data/database) and place each technology on it: HTML, CSS, and JavaScript in the browser; PHP, ASP.NET, JSP, and similar on the server; SQL against the database. Then classify each practice question by tier before reading the options.
Treating all image formats as interchangeable and picking GIF or BMP for photographic content, or PNG for simple animation, instead of matching format to content type and transparency/animation needs.
Candidates memorise 'GIF is compressed' and 'JPEG is compressed' without linking each format to its strengths: photographic gradients, flat colour and transparency, lossless graphics with alpha, or animation.
What to do instead
Build a comparison table with columns for colour depth, lossy versus lossy-free compression, transparency support, and animation, then attach one typical use case to each row (photographs, logos and icons, transparent overlays, simple animation). Answer format questions by matching the described content to the row.
Writing or evaluating CSS selectors with incorrect specificity or syntax, such as assuming an element selector overrides a class selector, or misreading descendant versus child combinators and pseudo-class notation.
Specificity is a rule candidates read once and rarely apply deliberately; in real projects they fix conflicts by trial and error, so the ranking of inline styles, IDs, classes, and element selectors is not reliably retained.
What to do instead
Memorise the ordering (inline style, then ID, then class/attribute/pseudo-class, then element/pseudo-element) and practise ranking sets of competing rules by hand. Also drill selector syntax: '.' for class, '#' for ID, space for descendant, '>' for child, ':' for pseudo-class, '::' for pseudo-element.
Confusing accessibility requirements with optional niceties, for example omitting alt text on decorative or functional images, or failing to associate form labels with their controls when the question describes a standards-compliant accessible page.
Candidates equate accessibility with 'adding alt text somewhere' and do not distinguish meaningful alternative text, empty alt for decorative images, label association, and keyboard operability as separate testable requirements.
What to do instead
Study the specific success criteria as discrete rules: every meaningful image needs equivalent alt text, purely decorative images take an empty alt, every form input needs a programmatically associated label, and content must be operable without a mouse. For each practice item, name which criterion is being tested before choosing.
Mishandling relative versus absolute referencing, choosing a root-relative or absolute URL where a document-relative path is required, or building paths that break when files are moved between directories.
Path resolution depends on the location of the referencing file, which candidates track loosely; they rely on their editor's autocomplete in practice and never reason about how the browser resolves '../' or a leading slash.
What to do instead
Practise tracing paths on paper from a stated file location: document-relative paths resolve from the current file, root-relative paths from the site root, and absolute URLs include the protocol and host. Work through several directory trees, writing the correct link from one file to another, including links that climb and descend multiple levels.
Ignoring the project management and planning phases in scenario questions, jumping straight to a technical solution when the question asks what should happen first in a site development lifecycle.
Technical candidates find planning questions less interesting and skim them, assuming the 'most advanced' answer is intended, whereas the exam rewards defining purpose, audience, requirements, and scope before design and implementation.
What to do instead
Learn the lifecycle as an ordered sequence (define purpose and audience, gather requirements, plan structure and content, design, implement, test, publish, maintain) and answer scenario questions by locating the described situation on that sequence. When an option describes building or coding, check whether the question places you earlier in the sequence.
Misreading questions about testing and quality assurance, for example choosing validation as proof of cross-browser rendering correctness or choosing a single-browser check as sufficient testing.
Candidates conflate markup validation, link checking, usability testing, and compatibility testing into one idea of 'testing', so any answer containing the word validation looks correct.
What to do instead
Separate the testing types by what each can and cannot detect: validation checks syntax against a DTD or schema, link checkers find broken references, compatibility testing confirms rendering and behaviour across browsers and devices, and usability testing observes real users. Match the question's described defect to the test that would actually reveal it.
Overlooking security and privacy basics in e-commerce and form questions, such as sending sensitive data by ordinary email, storing payment details locally, or treating client-side validation as a security control.
Candidates focus on functionality and forget that the exam tests awareness of secure transmission, server-side validation, and responsible handling of personal data as design requirements rather than afterthoughts.
What to do instead
Adopt a rule set: sensitive data travels over encrypted connections, all validation is repeated on the server because client-side checks can be bypassed, payment processing is delegated to a compliant provider rather than stored on the site, and collected personal data is limited to what the stated purpose requires. Apply the rule set to each scenario before reading options.