Question
Limits of Custom Sign‑in Page Accessibility in Okta OIE
Kavi Cedar
0 reputation · 14 Oct 2020, 03:30 UTC
51.4K views1
Loading…
0 reputation · 14 Oct 2020, 03:30 UTC
Okta’s Custom Sign‑in Page feature allows administrators to inject HTML, CSS, and JavaScript into the authentication UI to improve accessibility and branding. While the feature supports ARIA labels and color‑contrast adjustments for the initial login screen, its reach into the Multi‑Factor Authentication (MFA) challenge screens is less clear.
To determine whether an Okta Identity Engine (OIE) tenant can fully customize the accessibility of MFA challenge screens using the Custom Sign‑in Page editor.
The documented behavior indicates that while the initial login screen is fully customizable, the MFA challenge screens retain a more rigid structure. It is unclear whether OIE provides hooks for ARIA attributes or structural modifications on these screens.
35775 reputation · 14 Oct 2020, 07:56 UTC
In an Okta Identity Engine tenant, the Custom Sign-in Page editor does not provide editable ARIA hooks or structural customization for MFA challenge screens. ARIA labels on those screens are generated by Okta and not exposed for override. Custom CSS can be applied only within Okta’s branding allowlist and CSP constraints, and it is unsafe to alter focus order, hide error messages, or inject scripts on challenge steps. The internal layout of MFA challenges cannot be modified; only supported branding surface variables are allowed.
MFA challenge screens are rendered from a more rigid template than the initial login page. Custom HTML and JavaScript injected via the editor do not reliably apply to challenge steps, so full structural customization is not available.
ARIA attributes on MFA challenge screens are generated by Okta. The Custom Sign-in Page editor does not expose editable hooks to add or override ARIA labels for challenge widgets; accessibility is provided by Okta’s native markup.
Safe CSS use is limited to theme variables, colors, logo and spacing. Selectors that alter focus order or hide elements are risky and can break WCAG compliance and user awareness of failures.
Assumptions: OIE tenant with default widget rendering. Behavior is version and flow dependent; MFA factor types may have different rendering.
One diagnostic detail that changes the recommendation: which MFA factor type you need to customize, e.g., Okta Verify push, SMS, TOTP, or security questions. Coverage can vary by factor and release.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 14 Oct 2020, 13:09 UTC
It is important to distinguish between style persistence and script execution when customizing OIE flows. While custom CSS injected via the editor typically applies globally across the authentication session—allowing for color-contrast and basic visual adjustments on MFA screens—JavaScript behaves differently.
Because MFA challenge screens are often rendered as separate steps or dynamic updates, JavaScript intended for the primary sign-in page may not execute or persist during the MFA prompt. This creates a gap in accessibility: you can fix the color of a label via CSS, but you cannot reliably inject aria-label attributes or manage focus via JS on the challenge screens.
To verify this in your tenant, use browser developer tools to check if your custom CSS classes are present on the MFA DOM, and attempt to trigger a console.log via a script in the editor to see if it fires during the MFA transition.
okta