Accessibility of this Platform

Checked by automated rules

Two kinds of rule, both of which run on every change. An accessibility rule engine runs over every view in the route manifest and reports zero violations. Alongside it, checks over the source and the stylesheet assert the absences that undo the rest — a removed focus indicator, a hand-maintained focus order, a viewport that forbids zoom, an interaction that can only be driven by dragging. Automated rules detect a minority of WCAG failures, so this is evidence about these criteria and silence about the others.

1.3.1 Info and Relationships

Landmarks, heading levels, list structure and the association between each term and its description are machine-checkable. Whether the structure matches what the view looks like is not, and appears below.

2.1.2 No Keyboard Trap

Established as an absence rather than by a traversal: the shell registers no keyboard handler of any kind, so there is nothing that can intercept a Tab press, and it carries no positive tabindex, so there is no second focus order to escape from. Both are checked over the source. A traversal would be the stronger evidence and needs a browser that implements Tab.

2.4.2 Page Titled

Every route in the manifest declares a title, and the manifest refuses an entry without one.

2.4.7 Focus Visible

The default indicator is replaced, never removed. There is no rule anywhere in this application that sets outline to none, a check over every stylesheet asserts that, and a second check asserts the replacement is declared — an absent suppression would otherwise also be satisfied by a stylesheet that says nothing about focus and inherits a 1px browser ring. Whether the rendered indicator stands out against every surface the shell paints is the measurement under 1.4.11 below, which has not been taken.

2.5.7 Dragging Movements

New in WCAG 2.2, and established here the same way 2.1.2 is: as an absence. No element in the shell carries a draggable attribute or the deprecated drag ARIA, and nothing anywhere handles a drag event, a pointer move, a mouse move or a touch move — so there is no dragging movement to provide an alternative to. No rule in the stylesheet sets touch-action to none either, which is the declaration a hand-built gesture needs in order to take panning away from the browser, and therefore the fingerprint of one. Each of those absences is checked over the source. The criterion stops being free at the first reorderable list, slider or drag-to-arrange stage view, and that is what the check is for: the day one lands, this entry has to be rewritten around a single-pointer alternative rather than around an absence.

3.1.1 Language of Page

The lang and dir attributes are set on the document element by the server from the route's locale, for every route and before the first paint.

4.1.2 Name, Role, Value

Every control has a role and an accessible name computed from the rendered page. Whether the name is the right one is a judgement and appears below.

Checked by a scripted interaction test

A test drives the interface and asserts what happened: focus moved into the main region when the skip link was followed, focus moved again when the view changed, the live region was in the document before the message arrived. This covers behaviour a static scan cannot see, because a correct implementation and a broken one have the same markup.

2.1.1 Keyboard

Every interactive element in the shell is reached by Tab alone and activated by Enter. No control depends on a pointer.

2.4.1 Bypass Blocks

The skip link is the first element Tab reaches, and activating it moves focus into the main region — not merely the scroll position, which is what a skip link without a focusable target does.

2.4.3 Focus Order

Tab order follows the document, the document follows the route manifest, and focus moves into the main region after a client-side navigation rather than staying on the link that caused it.

4.1.3 Status Messages

The shell’s live region is present and empty from the first paint and is populated in place, which is the ordering a screen reader needs in order to announce it at all.

Measured from a rendered page in a browser

A browser run drives a real rendering engine over every view in the route manifest, at a desktop width and at the 320 CSS pixel reflow width, and runs the accessibility rule engine against the laid-out page. The two rules the layout-less suite cannot answer — the contrast of rendered text against what is painted behind it, and the size of each rendered target — are required to be answered, not left undecided. It reports zero violations, and the report it writes carries a digest of the source it measured, so a change to the shell without a fresh run fails the build. This is a measurement of these two criteria; it is not a conformance claim.

1.4.3 Contrast (Minimum)

Measured in a browser: the contrast of every piece of rendered text against what is painted behind it, after the cascade and inheritance, on every view at 1280 and 320 CSS pixels wide, with nothing below 4.5:1 (3:1 for large text) and nothing the engine could not decide. The declared palette is also recomputed from the WCAG relative-luminance formula on every change: body text is #1A1A2E on #F8F9FA at 16.2:1, secondary text is 8.0:1, and every posture notice keeps its light ink past 16:1 on its dark surface with each coloured rule past 4.5:1. Forced-colours mode is not in the run.

2.5.8 Target Size (Minimum)

Measured in a browser: the rendered box of every interactive target on every view, at 1280 and at 320 CSS pixels wide, is at least 24 by 24 CSS pixels or has the spacing the criterion allows instead, as the engine computes it from the laid-out page. The stylesheet declares the 24px minimum and the spacing; the run is what shows the rendered box honours them. The layout-integrity run adds English and Arabic at 360 and 1280 CSS pixels; the five languages that still render through the English fallback are not yet measured in their own words.

Not yet measured: needs a scripted browser measurement

These are measured from a rendered page, and the browser run that exists carries no rule for them: it computes the contrast of text and the box of each target, not the contrast of a focus indicator or a border against the surface behind it, and not whether a focused control is covered by something painted after it. The stylesheet declares values intended to pass each of them, and that intent is not a measurement. A scripted measurement in the same browser run is what settles them, and until it reports, these criteria are unverified rather than met.

1.4.11 Non-text Contrast

The focus indicator is a 3px outline at 2px offset, and the borders that carry meaning are #5C6B7A at 5.19:1 against the page — both chosen past the 3:1 this criterion asks of a non-text element, and both checked against the formula rather than estimated. The browser run measures the contrast of text only; no rule in it compares an indicator or a border against whatever is painted behind it, and that measurement has not been taken.

2.4.11 Focus Not Obscured (Minimum)

Nothing in the shell is sticky, floating or positioned over the content, so there is nothing that can cover a focused control. That is an argument from the stylesheet, not a measurement: the criterion compares the box of a focused element against the boxes of everything painted after it, no rule in the browser run makes that comparison, and the first view to introduce a sticky header makes the argument stop holding.

Needs review with assistive technology

These depend on judgement rather than structure: whether a label is meaningful, whether a heading describes what follows, whether a screen reader reads the view in an order that makes sense. No automated check settles them. They are open.

1.1.1 Non-text Content

The shell ships one decorative arrow glyph, hidden from assistive technology, and no informative image, so there is nothing for a rule to check and nothing to claim. Whether a future alternative text is useful is a human judgement in every case.

1.4.10 Reflow

Partly covered by the layout-integrity property, which asserts no truncation and no overlap from 360 CSS pixels upward in English and Arabic. Whether the reflowed view is usable is still a human reading of it.

2.4.4 Link Purpose (In Context)

That a link has an accessible name is checked mechanically. That the name tells a user where the link goes is not.

2.4.6 Headings and Labels

Heading levels and label associations are checked mechanically. Whether a heading describes its section is the criterion, and no tool reads for sense.

2.5.3 Label in Name

Checkable where a control has both visible text and an accessible name to compare. The shell avoids the failure by not overriding visible text with aria-label anywhere, which is a convention a reviewer has to confirm rather than a mechanism.

3.2.3 Consistent Navigation

The primary navigation is rendered once by the shell from one manifest, so it is identical on every view by construction. Confirming that is what a reviewer does.

3.2.6 Consistent Help

This statement is reachable from every view through the primary navigation. Whether it constitutes help, and whether its placement stays consistent as views are added, is open.

Not yet applicable to this build

These criteria govern interface elements this build does not have yet — forms, authentication, data tables, media. They are listed so that the view that introduces one inherits the obligation rather than discovering it.

1.3.5 Identify Input Purpose

The forms in this build are the language selector and the signing ceremony, both sets of buttons that collect no personal information. The Product_Profile view is the first one with input fields.

3.3.1 Error Identification

The signing ceremony is the first view that reports an outcome to the user: a refusal names the recorded reason, a failure names what did not happen, and each says that nothing was signed. No text input is validated yet; the four posture notices report a dependency failure rather than a user mistake.

3.3.2 Labels or Instructions

The language selector is labelled by its fieldset legend; the signing ceremony’s controls are buttons named by their visible text, and the manifest they act on is a description list read before them. No text input exists yet.

3.3.7 Redundant Entry

No multi-step process yet. The guided submission traversal is where this starts to apply.

3.3.8 Accessible Authentication (Minimum)

The signing ceremony’s gesture is a WebAuthn authenticator: nothing is transcribed, remembered or solved in this interface, and the device’s own unlock happens outside the page, which is not a cognitive function test. Session sign-in is not part of this build, so the criterion is stated for the ceremony only.

Reporting a barrier

If something here cannot be operated with a keyboard or a screen reader, that is a defect in this Platform. Report it to the MEDCO quality function through the internal issue process; it is handled as a product defect rather than as a suggestion.