The Parents' Portal Accessibility Audit
Transition Year students are rebuilding the parents' area of the school website. It shows timetables, exam results and a calendar. Decisions already made: exam results appear as green or red pills with no text label; helper text is #9AA0A6 on white; the class-selection dropdown is a <div> with a click handler and no key events; icon-only download buttons contain a Font Awesome <i> and no text; the homepage carousel auto-advances every 3 seconds and cannot be paused; and the results PDFs are scans. One parent is blind and uses NVDA on Windows. Another has low vision and browses at 200% zoom. The school has 900 families, and the portal is the only place results are published. The team has two weeks, no budget, and one member who can write JavaScript but has never tested with a screen reader.
1. Prioritise these defects. Explain the ranking in terms of who is blocked and whether they can work around it.
Read the worked answer
1. Scanned PDFs. A scan is an image; NVDA reads nothing. This blocks the blind parent from the single most important task on the site - getting their child's results - and the portal is the only publication channel, so there is no alternative route. Fix: export the PDFs from the source document as text, or as a last resort run OCR and check it. Highest priority because it is total exclusion and it has a cheap fix.
2. Colour-only results. Green/red with no label conveys meaning by colour alone. It fails for roughly 1 in 12 men with red-green colour vision deficiency, and it also fails in high-contrast mode and when printed. Add the word ("Pass", "Fail") or an icon plus text. Cheap, immediate, and affects a much larger group than the screen-reader user.
3. The <div> dropdown. It is invisible to NVDA and unusable without a mouse: no Tab focus, no arrow keys, no Enter. This blocks keyboard-only users, motor-impaired users and the blind parent, all at once, at the first interaction on the page.
4. Icon-only download buttons. The accessible name is empty or the raw glyph, so NVDA announces "button" and the user has no idea what it downloads.
5. Carousel. Auto-advancing every 3 seconds moves content faster than many people can read, distracts, and can steal focus. It has a standard remedy (a pause control) and is annoying rather than blocking - but it sits above the results, so it is not harmless.
6. Contrast. #9AA0A6 on white is about 2.6:1, well under the 4.5:1 required for normal text and under 3:1 for large text. Real, but it degrades rather than blocks.
2. For the class-selection dropdown, the team wants to keep the custom styling. Recommend what to build, given two weeks and no budget, and justify the trade-off.
Read the worked answer
Recommendation: use a native <select> and style what you can.
A native select gives you, for free and correctly on every platform: Tab focus, arrow-key and type-ahead selection, Escape, a visible focus ring, screen-reader announcement of the label, the current value and the list, and correct behaviour at 200% zoom. None of that has to be written or tested.
A custom <div> combobox can be made accessible, but "can be" is doing a lot of work. It needs role="combobox", aria-expanded, aria-controls, aria-activedescendant, tabindex, a keydown handler for Up/Down/Home/End/Enter/Escape, focus management that returns focus to the trigger on close, a live announcement of the highlighted option, and testing with at least NVDA and keyboard-only. That is a day or two for an experienced developer and considerably longer for a student who has never tested with a screen reader - and it will still be worse than the native control because the browser's implementation is already tuned to the operating system.
The trade-off is real but small: a native select's popup list cannot be styled beyond the closed control. The honest position is that the custom design was not a requirement anyone can point to - nobody asked for a bespoke dropdown, it was simply what got built. Ship the native select, style the closed state to match the design, and spend the recovered days on the scanned PDFs, which actually block a parent.
If the design later demands a filterable list, that is when to budget for a tested library or a full implementation - not two weeks before results day.
3. How would you test this in the time available, and what would you tell the principal, who likes the carousel and thinks accessibility is a nice-to-have?
Read the worked answer
Testing, cheapest first.
- Keyboard only. Unplug the mouse and tab through every page. Can you reach the dropdown, open it, choose a class, and get back out? This finds defects 3 and 4 in twenty minutes and requires no tools.
- 200% zoom and a narrow window. Does the timetable still work, or does it clip and overlap? Relevant to the low-vision parent and to every phone user.
- A screen reader. NVDA is free. The team member who can write JavaScript should install it, close their eyes and try to download a set of results. Five minutes will be more persuasive than any checklist. Listen for the accessible name of the icon buttons and whether the carousel's changes are announced and interrupt everything else.
- Automated checks (axe, Lighthouse) as a safety net for contrast and missing labels. Useful, but they catch only a fraction of real problems and they cannot tell you whether the PDF contains text.
- Ask the two parents. They already use the site and will find things no tool reports. This is the highest-value hour in the whole project.
To the principal: the argument is not "it is the right thing to do". It is that the portal is the only place results are published, so any parent who cannot use it has not been told their child's results. That converts an accessibility issue into a service failure and, for a publicly funded school, a legal exposure. The carousel can stay if it gains a pause button and stops auto-advancing - a small change, and the school keeps the design it likes. Frame the two weeks as: fix what blocks people first, polish second.