A 15-Second Banner That Must Be Editable, Fast and Safe
A Patna coaching institute wants a 15-second looping banner at the top of its homepage, with five scenes: logo, three subject icons each with one line of text, and a final 'Admissions open' panel showing a phone number and a date. Most visitors use low-cost Android phones about 360 px wide; a few use lab desktops. Office staff with no design training must be able to change the phone number and the admission date themselves. The earlier attempt was exported as an animated GIF at 800 x 400, 25 fps: 4.2 MB, with a gradient sky showing visible bands, jagged text edges, a phone number unreadable on a phone, and the page heading appearing only after the banner had loaded. One visitor complained that the flashing made them feel unwell. The site is maintained in a simple CMS by the office, with no developer on the payroll.
1. Choose the technique for the banner, and justify it against GIF, video and canvas using numbers from the case.
Read the worked answer
GIF is disqualified by arithmetic and format limits. 15 s at 25 fps is 375 frames, each restricted to a 256-colour palette, so banding in the sky gradient is a format property, not a settings mistake. Artwork drawn at 800 px and displayed at 360 px is downscaled by the browser, which is what produces the jagged small text. At 4.2 MB the file alone exceeds a sensible whole-page budget of about 1 MB and is roughly twelve times a well-compressed hero image.
Recommendation: HTML + CSS keyframe animation, with SVG for the icons. The scene text stays real text: sharp at any width, selectable, read by screen readers, and editable by office staff in the CMS. The weight is a few kB per SVG icon (1-3 kB) plus CSS, so the page stays far under budget and nothing waits on a large download.
Rejected alternatives: video (a 15 s MP4 at 1 Mbps is about 1.9 MB, and the text inside it can never be edited without re-exporting or read by assistive technology); canvas/JS (adds scripting for a five-scene loop, needs a scripted fallback and is hard to make accessible); GIF only as a single static fallback frame.
2. Explain the cause of each complaint (banding, unreadable text on phones, late heading, flashing) and give the fix for each.
Read the worked answer
- Banding: the 256-colour GIF palette cannot hold a smooth gradient. Fix: CSS linear-gradient or an SVG gradient, which are not palette-limited; if a raster image is unavoidable, add subtle noise or dithering and re-test on a cheap phone screen, which exaggerates banding.
- Unreadable phone number at 360 px: the text was rasterised at 800 px and scaled down, and most likely set smaller than 16 px equivalent. Fix: real text at 18-20 px minimum, one short line per scene, tested at 360 px width with wrapping allowed; never place essential contact details in an image.
- Heading appears after the banner: the 4.2 MB banner blocked rendering. Fix: put the banner in the document itself (HTML/CSS), declare width and height to reserve space, and avoid any large blocking resource above the fold.
- Flashing: WCAG requires no more than three flashes in any one second and no large flashing areas. Fix: drop flashes entirely, use a short fade or slide (300-500 ms) between scenes held for about 3 s each; respect prefers-reduced-motion by showing a static frame; if the loop runs longer than 5 s, provide a pause control.
3. The staff must be able to change the phone number and date without a developer. Evaluate how each candidate technique behaves on that requirement.
Read the worked answer
This is the requirement that should drive the choice, because it decides the cost of every future edit.
- GIF or video: the number and date are pixels. Each change means finding whoever has the source, re-exporting, re-uploading and re-testing. With no developer on the payroll, edits simply do not happen and the site ends up advertising last year's date.
- Canvas/JS: possible to make editable, but the text lives in a script or a data file that office staff will not touch safely, and an error blanks the whole banner.
- HTML/CSS (recommended): the five scene texts sit in ordinary CMS fields; the animation applies to wrappers, not to content, so changing 'Admissions open till 30 June' is a text edit followed by Save. Nothing can break visually because the length of a sentence does not affect the CSS keyframes.
Rule to state to the institute: if a piece of content changes more than once a month, it must not be baked into an image, GIF or video. If a timeline tool is ever used for the artwork, keep the editable source file, export both a static poster and a video fallback, and record the re-export as a known cost per edit.