The AI Pipe

WeGuide public-login checks

A replayable harness pointed at the WeGuide screens reachable without an account, on app.weguide.com.au and movement.weguide.health. Run twice on 14 September 2026, in 3 viewport conditions, with axe-core 4.13.0 and a scripted Playwright sequence. Each line records what a machine saw, how to see it again, and which criterion it might belong to; the judgement, the severity and the signature stay with a specialist.

Screens: 7
Runs: 2, twenty minutes apart
axe rules run: 65
Engine: axe-core 4.13.0, Chromium 153
Reviewed by a specialist: none yet

Why an ordinary axe run reports almost nothing here

The portal overrides the native DOM child accessors on <ion-app>, <ion-input>, <ion-alert>: those elements report no child nodes while holding real children, and any engine that walks a page through childNodes stops there. On the sign in screen axe-core saw 106 nodes as served and returned meta-viewport(1). With the native accessors restored inside the scan, it sees 251 nodes and returns aria-valid-attr-value(1), color-contrast(1), label(1), meta-viewport(1), role-img-alt(2). Nothing is sent to the site. A near empty automated report on this portal is not evidence that the portal is clean.

One observation, all the way through

A list of defects is easy to produce and hard to act on. A loop is not: seen, handed over with its interpretation kept separate, checked again later by the same control.

1. Observed

A template expression was left in an ARIA attribute

On the sign in screen the Login button carries aria-disabled="getErrors(false).length? 'true' : 'false'". The framework binding was written as a literal string, so the expression reaches the browser un-evaluated. Assistive technology reads that value as neither true nor false.

<button type="button" class="button-native" part="native" aria-disabled="getErrors(false).length? 'true' : 'false'">

The Login button on the WeGuide sign in screen, outlined, with a caption reading: aria-disabled holds an un-evaluated template expression. — Sign in screen at 1280×800. The outline and caption were drawn by the capture script; the rest is as it rendered.

2. Handed over

Proposed criterion, not reviewed

4.1.2 Name, Role, Value (A)

Accessibility review

Pending a specialist

Proposed remediation. Bind the attribute rather than writing it as a string: [attr.aria-disabled]="getErrors(false).length > 0".

Plain text for GitHub or Jira, no integration.

3. Retested

The same control runs again later, and answers only while it still has its subject: the screen must render, the element must be there, the rule must execute. Below it runs against a small synthetic screen carrying the same four defect shapes, corrected in the repository. A local demonstration.

The same four controls against three local variants of one screen
Control	as observed	corrected	form deleted
label	reproduced	not reproduced	cannot conclude
aria-valid-attr-value	reproduced	not reproduced	cannot conclude
role-img-alt	reproduced	not reproduced	cannot conclude
meta-viewport	reproduced	not reproduced	not reproduced

The third column is the one that matters. Deleting the form makes three controls go quiet and the harness answers cannot conclude, not fixed. The fourth survived the deletion and was genuinely corrected, so it may report not reproduced.

Everything the two runs recorded

findings.json the harness

10 appeared in both runs, 2 are open questions. Severity is the impact axe gives its own rule, and the criterion beside each line is a proposal for a specialist to accept or throw out.

Observations on the public WeGuide screens: proposed criterion, axe impact, whether both runs reproduced it, and the review status
SC	Observation	Screens	axe impact	Evidence	Review
4.1.2	A template expression was left in an ARIA attribute	Patient portal	critical	reproduced	pending
4.1.2	Form fields have a visible label and no accessible name	2 screens	critical	reproduced	pending
1.4.4	The viewport meta tag switches pinch zoom off	4 screens	moderate	reproduced	pending
2.4.7	Focusing a portal text field changes nothing on screen	2 screens, desktop	measure	reproduced	pending
1.4.3	axe flags the Login and Submit buttons for contrast, and they are inactive	2 screens	serious	to investigate	pending
4.1.3	The empty submit shows an error in red, and no live region carries it	Patient portal, desktop	measure	to investigate	pending

A template expression was left in an ARIA attribute
4.1.2 Name, Role, Value, Level A
Patient portalaxe impact criticalreview pending
reproduced
Form fields have a visible label and no accessible name
4.1.2 Name, Role, Value, Level A
2 screensaxe impact criticalreview pending
reproduced
The viewport meta tag switches pinch zoom off
1.4.4 Resize Text, Level AA
4 screensaxe impact moderatereview pending
reproduced
Focusing a portal text field changes nothing on screen
2.4.7 Focus Visible, Level AA
2 screens, desktopaxe impact measurereview pending
reproduced
axe flags the Login and Submit buttons for contrast, and they are inactive
1.4.3 Contrast (Minimum), Level AA
2 screensaxe impact seriousreview pending
to investigate
The empty submit shows an error in red, and no live region carries it
4.1.3 Status Messages, Level AA
Patient portal, desktopaxe impact measurereview pending
to investigate

Where this stops and where your specialist starts

Not covered here

Everything behind a sign in, and the mobile application.
Screen reader passes with NVDA, JAWS and VoiceOver.
Whether an alt text is meaningful or a reading order sensible.

Yours to decide, not the tool's

Which criteria apply to which screens, and what the sample is.
Whether each proposed criterion is right, and if an exception applies.
Severity, priority, the assessment, and the signature at the end of it.

What the measurements could not settle is written out in findings.json. The harness earns its place where an expert's hours cost more than a machine's. Fifteen minutes to talk it through.