Can FirebaseUI's sign-in widget meet WCAG 2.1 AA, or is a custom Auth SDK form the safer path?

Answer

For most teams that require a guaranteed WCAG 2.1 AA experience, a custom form built directly on the Firebase Auth SDK is the safer path. The current FirebaseUI v6.x widget does not expose sufficient hooks for focus management or error announcement, and its internal markup can trap focus after OAuth redirects or when the widget is re-shown. A custom implementation gives you full control over labels, aria-live regions, and autocomplete attributes, enabling a deterministic focus order and reliable error announcements.

Why FirebaseUI Falls Short

• FirebaseUI renders its own DOM and does not provide public callbacks for moving focus or announcing failures.
• While the widget includes basic ARIA roles (e.g., role="dialog"), the focus can become trapped after an OAuth redirect or when the widget is re-shown.
• Accessibility of third-party provider screens (OAuth consent, reCAPTCHA) is out of the developer's control in both approaches, but the widget's own markup does not guarantee screen-reader friendliness across all releases.

When a Custom Form Is Worth the Effort

Building directly on the Firebase Auth SDK requires implementing and maintaining the full set of flows:

1. Email/password sign-in
2. OAuth sign-in via popup or redirect
3. Phone OTP verification
4. Email-link sign-in

With this control you can:

• Apply consistent label and aria-label attributes.
• Use aria-live="polite" regions to announce errors.
• Set autocomplete="one-time-code" on OTP inputs.
• Restore focus to a logical element after a redirect.

Most Fragile Flow: signInWithRedirect

The redirect round-trip is the most delicate part of a custom implementation. After the user returns from the provider's consent screen, you must explicitly focus an element on the redirect URL (e.g., the first interactive control) and ensure that focus is not lost on page reload. Failure to do so can trap keyboard users and break screen-reader navigation.

Phone OTP Entry

Phone OTP requires careful design for accessibility, but the scope is smaller. Use type="tel", provide clear labels, and add autocomplete="one-time-code" to aid autofill. The primary risk is ensuring that the OTP modal is announced correctly by the screen reader.

Practical Verification Steps

1. Inspect the generated DOM of FirebaseUI in the target version to confirm ARIA attributes and modal behavior.
2. Run a keyboard-only navigation test in a modern browser with NVDA or VoiceOver to check that all controls are reachable and focus returns logically after OAuth redirects.
3. Create a minimal custom form using the Firebase Auth SDK, add explicit aria-live regions, and perform a screen-reader audit to confirm error announcements.
4. Test the signInWithRedirect flow by capturing the redirect URL, restoring focus to a meaningful element, and verifying behavior after a page refresh.

Missing Diagnostic Detail

To fine-tune the recommendation, could you confirm whether you need to support older browsers (e.g., Internet Explorer 11) or specific screen readers (e.g., JAWS)? This detail may influence the choice of implementation strategy.