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

The goal is a sign-in flow that survives a keyboard-only and screen-reader audit against WCAG 2.1 AA: labeled controls, announced errors, and predictable focus — including after an OAuth redirect returns the user to the app.

FirebaseUI for Web (the v6.x line at the time of writing, on top of the modular Firebase JS SDK) ships a drop-in widget, but it renders and manages its own markup. Its documented callbacks, signInSuccessWithAuthResult and uiShown, offer no documented hook for moving focus or announcing failures, and accessibility conformance appears to vary between releases, so version-specific behavior needs verification.

Building directly on the Firebase Auth SDK — signInWithEmailAndPassword, signInWithPopup/signInWithRedirect, phone auth, and email-link sign-in — would give full control over labels, aria-live regions, and autocomplete="one-time-code" on OTP fields, at the cost of implementing and maintaining every flow ourselves. Third-party surfaces such as reCAPTCHA and provider consent screens stay out of our control either way.

Does the current FirebaseUI release expose enough DOM and callback control to pass an accessibility audit, or is a custom SDK-based form the realistic route? And if we build custom, which flow needs the most careful design first: the signInWithRedirect round trip or phone OTP entry?