Rebuilding a School Site That Fails Its Own Parents
Analytics for a school website show 68% of visits from phones about 360 px wide, 20% from desktops, and 12% from the computer lab using keyboards only. The site uses a fixed 1024 px wrapper, a table-based layout, navigation built from div elements whose links appear only on :hover, body text at 11 px in #999999 on white, and four separate h1 tags chosen for their size; one h3 appears before any h2. Every image carries alt='image'. Form fields use placeholder text instead of labels, and the 'read more' links all say 'click here'. The main photo is a 2.8 MB JPEG displayed at 400 x 250. A blind parent using a screen reader reports that the menu reads as 'link link link' with no names, and a low-vision teacher who zooms to 200% says the layout overlaps. The head teacher wants a prioritised list and an idea of effort.
1. Rank the main failures by harm and frequency, and support the ranking with the numbers available.
Read the worked answer
1. Contrast and text size. #999999 on #ffffff is 2.85:1. WCAG 2.1 AA needs 4.5:1 for normal text, and 3:1 only for large text (about 24 px, or 18.66 px bold). 11 px grey fails both the ratio and any comfortable reading size, and zooming cannot fix contrast. A safe minimum grey on white is #767676 (about 4.54:1). Fix: 16 px body text at #333 to #595959. Affects nearly every visitor. 2. Navigation. Hover-only div menus are invisible to keyboard users (there is no focus state), unreachable on touch (there is no hover), and give a screen reader anchors with no usable name. This is exactly the parent's complaint and it blocks the 12% keyboard cohort completely. 3. Heading structure. Four h1s and an h3 before any h2 destroy the outline screen reader users navigate by; size should come from CSS, not from tag choice. 4. Alternative text. alt='image' is worse than nothing: it announces a meaningless word dozens of times instead of describing purpose. 5. Labels and link text. Placeholders vanish on typing and are read as a value, not a name; 'click here' is meaningless out of context. 6. Layout and weight. A 1024 px fixed table forces horizontal scrolling on a 360 px screen and linearises into confusing reading order; a 2.8 MB image shown at 400 x 250 wastes most of its bytes on every mobile visit. Order by harm x frequency: contrast, navigation, image weight, then semantics, then layout. Effort: contrast, headings, alt text and labels are hours in the template; resizing images is one bulk job; replacing the table layout is the only multi-day item.
2. Rewrite the structure of the page in outline: what replaces the table, the div menu, the headings, the alts and the form fields?
Read the worked answer
- Page shell: a skip link first, then header, nav, main, footer. Each landmark once, so a screen reader can jump straight to main content instead of tabbing through 30 menu items.
- Navigation: nav containing ul/li/a, with the current page marked aria-current='page'. The menu is visible by default and on :focus-within, so keyboard and touch users both reach it; no dependence on hover.
- Headings: one h1 carrying the page's real title, then h2 for sections and h3 for subsections, in order and with no skipped levels; visual size is set in CSS so the tag choice is free.
- Images: decorative images get alt='' (announced as nothing, correctly skipped); informative images get a short statement of purpose, e.g. alt='Class 9 students at the district science exhibition, 2024'; images that are links describe the destination.
- Forms: every field has a visible label bound with for/id, the placeholder is only an example, required fields are marked in text as well as by colour, and errors are announced next to the field.
- Links: link text describes the destination ('Download the 2025 admission form (PDF, 120 kB)') rather than 'click here'.
- Layout: div and CSS grid/flex replace the layout table; a data table stays only for actual tabular data, with th and scope.
3. The head teacher asks how to make the site work on a 360 px phone and at 200% zoom without breaking. Set out the approach and the tests that prove it.
Read the worked answer
Markup: add the viewport meta tag (width=device-width, initial-scale=1) - without it a phone renders the page at about 980 px and scales it down, which is why the fixed 1024 px wrapper produces horizontal scrolling and tiny text.
CSS: replace the fixed 1024 px wrapper with a fluid container (width 100%, max-width around 1100 px, padding in relative units). Use a single breakpoint near 600 px for the two-column desktop layout to become one column, and let grids use minmax/auto-fit so they reflow without extra breakpoints. Set images to max-width: 100% and declare their width and height so space is reserved and the page does not jump. Size type in rem so the browser's zoom and the user's font settings both take effect.
Why hover menus had to go: on touch there is no hover state, so a hover-only menu is simply unreachable; a keyboard-only user also never triggers hover. A menu that opens on focus and on tap solves both.
Tests that prove it: (1) open the page at 360 px width in the browser's device mode and check for horizontal scrolling; (2) set zoom to 200% at 1280 px and confirm no overlap and no clipped text; (3) tab through the whole page and confirm focus is always visible and the menu opens; (4) run a screen reader through the menu, headings and form; (5) check the main photo has been resized to about 800 x 500 and compressed to roughly 100-150 kB; (6) re-check contrast with a colour-contrast tool, not by eye.