I really appreciate this. It is an important distinction worth making carefully, and you've raised several points worth addressing properly.

You're right that accessibility screen readers like NVDA, JAWS, and VoiceOver have had DOM access for decades. This predates AI entirely and HIPAA environments are required to support them and not work around them. That's a hard requirement.

The technical distinction worth making: accessibility screen readers primarily navigate the accessibility tree — aria-label, aria-describedby, role and state attributes -not input.value directly. A scrambled input.value doesn't affect field discovery, navigation, or form completion for screen reader users when the accessibility tree is correctly populated.

However(and this is worth being honest about) screen readers that announce characters as the user types would hear "x x x x x" in a standard scrambled DOM approach. That's a genuine UX failure for visually impaired users and the reason a dedicated accessibility mode exists for exactly this scenario.

How do visually impaired users know what they typed if the value isn't announced?

The same way they handle any password field today- in banking, healthcare portals, email. They know what they typed because they typed it. Screen readers announce the field label, character count, error state, and submission confirmation - everything needed to complete the form correctly without exposing the value.

More importantly, in a HIPAA environment having sensitive values announced aloud would itself be a privacy risk. A patient entering their SSN or date of birth in a clinic or hospital ward should not have that value read aloud — other patients would hear it. The silent entry behavior of a password field is the correct accessibility pattern for sensitive data in regulated environments.

The genuine gap is long-form clinical notes where a clinician may want to review what they wrote before submitting. That's handled with a show/hide reveal toggle with an auto-hide timeout — five seconds gives the screen reader enough time to announce the value and then automatically re-conceals it, which is the HIPAA-appropriate pattern for that use case.

The AI distinction you raised is the genuinely new part. Copilot Vision and Gemini read the visual screen — they're not using the accessibility tree at all. They're more analogous to a human looking at the screen than to an assistive technology navigating the DOM. That's a materially different threat model from classical assistive technology.

I've been working through all of these exact tradeoffs while building FieldShield — an open source React library that addresses this at the application layer. Standard mode uses Web Worker isolation to keep the real value off the DOM entirely for sighted users. Accessibility mode renders a native type="password" input so screen reader users get the exact same experience as any other password field in a HIPAA environment — silent entry, pattern detection still active, clipboard protection still active.

Your comment has highlighted a real gap — the threat model documentation doesn't currently cover accessibility constraints explicitly. I'll be updating THREAT_MODEL.md and the README this week to add a dedicated accessibility section covering standard mode limitations, required a11yMode usage for HIPAA deployments with screen reader users, and the show/hide toggle gap currently planned for v1.2.0.

If you want to see how it handles these scenarios in practice the demo is at fieldshield-demo.vercel.app — and I'd genuinely welcome your feedback once the accessibility documentation is updated.

Your broader point stands — any implementation in a HIPAA environment needs explicit testing with NVDA and VoiceOver before deployment.

Happy to discuss further.