Could someone reach the search field, open the right result and find the information they needed? I set out to examine that route across eight Korean health-information portals using keyboard input and page structure. During repeated collection, the same task received different classifications, and several apparent barriers turned out to be collector errors. On July 15, 2026, I stopped the project without publishing portal scores or rankings.
The problems emerged in the program gathering the results. It pressed specified keys and recorded which element received focus and which page state followed a search. Tracing the unexpected results led to rules that treated different links as one element or counted an unrelated page change as a successful search.
Fixing what each run was meant to examine
The portals organized search and detailed information differently. I specified the query, the target record’s identifier and the information field to inspect, then documented how to reach the initial search page, results list and detail page. A change in result order was not a reason to switch to the first item. A changed target or route was a reason to stop collection. What I froze was the measurement target and its selection rules, not the website itself.
There were four tasks: identify the correct search control, submit the fixed query, open the target result and find the specified information in its detail page. If a page had several input fields, the first task depended on identifying which one belonged to that route.
On July 14, the preparation package passed all 37 of its tests, and the evidence files and hashes matched across the eight portals. A hash lets a stored file be checked for changes. The planned axe collection—using a tool that automatically checks accessibility rules—contained 48 measurements: eight portals, three page states and two repetitions. None of those measurements had yet been run. The 37 tests checked the package being prepared for collection.
The keyboard-and-DOM work that later exposed problems was a separate collection process. The DOM is the structure of page elements handled by the browser. The script pressed keys such as Tab and Enter, tracked focus, and read the roles and names the browser assigned to elements. The plan also called for a separate task audit using NVDA, a screen reader that reads screen content aloud.
Different links became the same focus stop
The first scripted run covered four tasks on each of the eight portals and flagged keyboard traps in 16 of the 32 tasks. A keyboard trap prevents focus from moving out of an element or region. Inspection of the traces showed that the collector had assigned the same identity to different links without IDs.
It built an element key from a selector—the expression used to locate an element—and that element’s role. When a link lacked a unique ID, its selector collapsed to the tag name a, giving different links the same key, a|link. In one trace, 21 successive stops on different links were stored under that key. The collector interpreted this as remaining on one element for at least 20 stops, ended the traversal, and then reported that it could not reach a search field farther along the route. I excluded the whole run from analysis while retaining its records and the reason for exclusion.
After the collector was revised, another run treated a select box as a search input. Choosing candidates by their browser-computed role had led it to a search-category dropdown, where it tried to type and submit the query. There was also a state-labeling problem on dynamic pages without a fixed detail URL: the collector reopened the search page but recorded it as the detail page. Depending on whether the target wording happened to appear there, this could generate either a false success or a false failure.
A later run exposed a loose definition of search success. Pressing Enter after entering the query opened an unrelated record’s detail page. The collector recorded success because the page’s text differed from its text before the action. It had checked for a change, but not for arrival at the results list containing the fixed target. A subsequent run also selected hidden menu text as the target information and missed the visible heading and value in the body.
Looking again at a task whose classification changed
The July 15 QA6 report records one task against the same frozen target as I in three earlier runs and W in the next. In this collection method, I meant completion using only the allowed keys; W meant that a workaround, such as a mouse action, had been used.
The page had more than 200 focus stops and menus that expanded when focused. The report identified rendering timing and changes in Tab order as possible causes. There was also a gap in the input specification. Fixing a query and a target result did not specify the exact field into which the query should be entered. The collector still had to choose between a site-wide header search and a search field within the content.
A follow-up review clarified another traversal limitation. Some screenshots saved as evidence of focus in the results state actually showed the header or the area around a skip-to-content link. Even where a user could jump into the body, the collector’s sequential Tab traversal could stop before reaching the results region. The review classified these captures as not measured for that region, rather than accepting them as evidence of its focus behavior.
Keeping the reasons for exclusion
I retained the frozen protocol, regression tests, QA documents, raw traces and exclusion notes for each run. Excluding a run from analysis did not mean deleting its files: the records needed to show how an implementation rule had produced a false finding. Separating page-level problem candidates from errors introduced by the collector came first, and I did not publish portal-level accessibility judgments from this material.
A restart would begin by specifying each task’s search input and results region, then checking the route all the way to the target information. Runs under the same conditions would then be compared for matching task classifications and for matching barrier codes, which identify problems such as keyboard traps. Before collecting again, the method would need to distinguish failure to reach the target from failure by the site itself.