Other Occurrences — Non-text Elements and Focus Indicators
When we scan a page, the same problem often shows up many times. A navigation bar with 8 buttons that all use the same washed-out blue is not 8 different problems — it is one problem repeated 8 times.
So instead of publishing 8 separate findings, the report publishes:
- 1 main finding — with the full explanation, the screenshot, and the recommended fix.
- 7 "other occurrences" — a numbered list underneath, each one pointing to its own element on the page.
Think of it like a supermarket receipt: it does not print "apple" six times on six lines. It prints "apple × 6". Same information, far less noise.
Why we do it: the person reading the report fixes the problem once — usually one line of CSS — and it is solved everywhere. Showing 8 tickets with the same recommendation makes the report look worse than the site actually is, buries the genuinely different problems, and wastes the reviewer's time reading the same paragraph eight times.
Two things always hold, regardless of the case:
- The first occurrence found while reading the page top to bottom becomes the main one. It is the one the user will see first when they open the page.
- Every occurrence in the list keeps its own location and its own name, so each one can still be found and highlighted individually on the page.
Case 1 — Non-text elements
These are the visual parts of a page that carry meaning without using words: icons, borders around input boxes, button backgrounds, checkboxes, toggles, progress bars, chart segments.
What decides that two occurrences are "the same": the pair of colours involved in the problem — the colour of the element itself, and the colour right behind or next to it. If two elements show the same colour pairing, they are treated as the same problem.
Two details matter here.
Colours are cleaned up before comparing. The same colour can be written several ways (#EEEEEE, rgb(238, 238, 238), plus transparency information). Before comparing, every colour is rewritten into one standard notation and the transparency is dropped. It is like comparing two phone numbers after removing spaces and dashes — 555 123-4567 and 5551234567 are obviously the same number, but only once you strip the formatting.
For the general contrast check on non-text elements, comparison is by colour name, not by exact shade. A shared list of 13 colour names is used — black, white, gray, red, orange, yellow, green, teal, cyan, blue, purple, pink, brown — and each colour on the page is sorted into the closest one. This is the same list already used for text. The analogy: you do not file two shirts under "navy #1F3A93" and "navy #22417F" — you file both under "blue". So two buttons whose blues differ by an amount nobody can perceive land in the same group instead of producing two near-identical findings.
The stricter checks — an element's focus colour against its background, a selected tab against an unselected tab, a control's border against its surroundings — require the colours to match exactly, not just by name. In these cases a small shade difference genuinely can be a different problem with a different fix, so they are not blurred together.
One extra safeguard: for controls checked against their surroundings, the kind of problem also has to match. A "your selected state is not visible enough" finding never merges with a "your border is not visible enough" finding, even if the colours line up. Same colours, different symptom, different fix.
Case 2 — Focus indicators
A focus indicator is the visual mark showing which element is currently selected when someone navigates with the Tab key instead of a mouse — usually a ring, an outline, or a change of background colour. Without it, a keyboard user is typing blind.
Here the grouping is not based on what colour the element is. It is based on what changes when you tab onto it.
What decides that two occurrences are "the same": the before → after colour transition, plus which visual property changed.
- Six navigation links that all go from the same blue to the same lighter blue when focused → one group. Same transition, one fix.
- Two buttons that go from that same starting blue to a different lighter blue → a separate group, because the destination colour differs.
- A button whose border changes never merges with a button whose background changes, even with identical colours — different property, different fix.
Here the before and after colours must match exactly, not by colour name. This check measures whether the difference between the two states is big enough to notice. Rounding the shades to a name would blur exactly the thing being measured — like rounding two people's heights to "tall" and then trying to say which one is taller.
One special case: elements with no focus indicator at all are merged into a single finding, no matter what colour they are. There is no colour transition to compare, because there is no transition happening — that is the bug. Everything with the same complete absence goes in one place.
The difference in one line
| Grouped by | Colour matching | |
|---|---|---|
| Non-text elements | The colours the element shows right now — the element plus what is behind it | By colour name for the general contrast check (the shared 13-name list, same as text); exact for the stricter state checks |
| Focus indicators | The colour change before → after tabbing onto it, plus which property changed | Exact — the size of the change is the thing being measured |
| Missing focus indicator | Nothing — all merged | Not applicable, no colours involved |
Plain version: for non-text elements we ask "what does it look like?"; for focus indicators we ask "what does it do when you tab to it?" — and when the answer is "nothing at all", they all become one finding.