[fedcm] Introduce a <login> element to the accessibility parse tree [chromium/src : main]
Sam Goto (Gerrit)
Sam Goto added 1 comment![]( "Open in Gerrit")
@foo...@chromium.org, wdyt?
This seemed better to me than to extend the Annotated Page Content mojom service, because I wanted to get all of the benefits of the accessibility tree (like synchronizing JS updates with the DOM).
Is this an appropriate use of the accessibility tree? Otherwise, I'd be happy to move this elsewhere.
Related details
- Philip Jägenstedt
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
AI Code Reviewer (Gerrit)
AI Code Reviewer added 1 comment![]( "Open in Gerrit")
ax::mojom::blink::Role::kLogin,nit: Please keep the list sorted alphabetically to maintain consistency. 'kLogin' should appear before 'kRegion'.
To keep this interaction as brief and non-intrusive as possible, please consider responding with one of following options:
**Done** | **OK But Won't Fix**: reason | **Later**: b/<bug_id> | **Invalid:** reason
_This comment was generated by [Experimental Blink C++ Code Review Agent](http://go/blink-c++-code-review-agent)._
_AI reviews can sometimes be inaccurate; We appreciate your 🙏 feedback 🙏 to help us improve._
_[File a bug](http://go/blink-c++-code-review-agent-feedback) | [Provide feedback on chat](https://chat.google.com/room/AAQA0zhQHe0?cls=4) | [Opt-out](https://ganpati2.corp.google.com/group/peep-genai-blink-agent-optout.prod)_
Related details
- Philip Jägenstedt
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Philip Jägenstedt (Gerrit)
Philip Jägenstedt added 1 comment![]( "Open in Gerrit")
dgrogan@ can you take a look? How should one go about picking the most appropriate mapping on each platform? I think this would be defined in https://w3c.github.io/html-aam/ but following the reference to https://developer.apple.com/documentation/appkit/nsaccessibility I can't find an obvious choice.
Related details
- David Grogan
- Sam Goto
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
David Grogan (Gerrit)
David Grogan added 1 comment![]( "Open in Gerrit")
dgrogan@ can you take a look? How should one go about picking the most appropriate mapping on each platform? I think this would be defined in https://w3c.github.io/html-aam/ but following the reference to https://developer.apple.com/documentation/appkit/nsaccessibility I can't find an obvious choice.
Yeah, there's nothing obvious to me either. Sam, when you're even kind of sure that you're going to introduce a new <login> element, file an issue on https://github.com/w3c/html-aam/issues/ asking for ARIA's guidance for mappings for this new element. (Are you already kind of sure? If so, go ahead and file.)
There's also https://w3c.github.io/html-aam/#mapping_nodirect , which this CL might already abide by, honestly. (Not sure what comes out in the description --
https://w3c.github.io/core-aam/#accessible-names-and-descriptions -- for login elements.) It's no big deal, for now, if it doesn't though.
In the meantime, seems like Sam is just [ab]using chrome's axtree as a place for convenient access. That's fine. As long as that usage isn't going to require expanding the axtree's (or syncing) performance or behavior beyond what is required for a11y purposes.
Related details
- Philip Jägenstedt
- Sam Goto
Sam Goto (Gerrit)
Sam Goto added 1 comment![]( "Open in Gerrit")
David Grogandgrogan@ can you take a look? How should one go about picking the most appropriate mapping on each platform? I think this would be defined in https://w3c.github.io/html-aam/ but following the reference to https://developer.apple.com/documentation/appkit/nsaccessibility I can't find an obvious choice.
Yeah, there's nothing obvious to me either. Sam, when you're even kind of sure that you're going to introduce a new <login> element, file an issue on https://github.com/w3c/html-aam/issues/ asking for ARIA's guidance for mappings for this new element. (Are you already kind of sure? If so, go ahead and file.)
There's also https://w3c.github.io/html-aam/#mapping_nodirect , which this CL might already abide by, honestly. (Not sure what comes out in the description --
https://w3c.github.io/core-aam/#accessible-names-and-descriptions -- for login elements.) It's no big deal, for now, if it doesn't though.In the meantime, seems like Sam is just [ab]using chrome's axtree as a place for convenient access. That's fine. As long as that usage isn't going to require expanding the axtree's (or syncing) performance or behavior beyond what is required for a11y purposes.
In the meantime, seems like Sam is just [ab]using chrome's axtree as a place for convenient access. That's fine.
Yeah, I think that's exactly what I'm trying to do: using chrome's axtree (and hopefully not abusing it) for convenient access. If this is an abuse (and please, do feel free to point me another way!) with unintended consequences (e.g. messing up with screen readers) there are probably different ways that I can accomplish the same goal here (e.g. using the Annotated Content Proto for AI agents?).
As long as that usage isn't going to require expanding the axtree's (or syncing) performance or behavior beyond what is required for a11y purposes.
Yeah, I'm not sure if I can be a good judge of this, so do please LMK if that's the case.
Specifically, I think it is early enough that I don't know if I can answer these questions:
Sam, when you're even kind of sure that you're going to introduce a new <login> element, file an issue on https://github.com/w3c/html-aam/issues/ asking for ARIA's guidance for mappings for this new element. (Are you already kind of sure? If so, go ahead and file.)
I think it is plausible that this <login> element will behave more like the <geolocation> element more than <search> or <main>, so I wanted to make sure that I have something that I can play with without cornering myself.
Can you help me understand something? Will this CL actually have any affect on screen readers? Like, if a user runs into a website with a <login> element, with this CL patched in, will their user experience change in any shape or form?
If so, I think this is probably not the right approach to this problem.
Related details
- David Grogan
- Philip Jägenstedt
Sam Goto (Gerrit)
Sam Goto added 1 comment![]( "Open in Gerrit")
David Grogandgrogan@ can you take a look? How should one go about picking the most appropriate mapping on each platform? I think this would be defined in https://w3c.github.io/html-aam/ but following the reference to https://developer.apple.com/documentation/appkit/nsaccessibility I can't find an obvious choice.
Sam GotoYeah, there's nothing obvious to me either. Sam, when you're even kind of sure that you're going to introduce a new <login> element, file an issue on https://github.com/w3c/html-aam/issues/ asking for ARIA's guidance for mappings for this new element. (Are you already kind of sure? If so, go ahead and file.)
There's also https://w3c.github.io/html-aam/#mapping_nodirect , which this CL might already abide by, honestly. (Not sure what comes out in the description --
https://w3c.github.io/core-aam/#accessible-names-and-descriptions -- for login elements.) It's no big deal, for now, if it doesn't though.In the meantime, seems like Sam is just [ab]using chrome's axtree as a place for convenient access. That's fine. As long as that usage isn't going to require expanding the axtree's (or syncing) performance or behavior beyond what is required for a11y purposes.
In the meantime, seems like Sam is just [ab]using chrome's axtree as a place for convenient access. That's fine.
Yeah, I think that's exactly what I'm trying to do: using chrome's axtree (and hopefully not abusing it) for convenient access. If this is an abuse (and please, do feel free to point me another way!) with unintended consequences (e.g. messing up with screen readers) there are probably different ways that I can accomplish the same goal here (e.g. using the Annotated Content Proto for AI agents?).
As long as that usage isn't going to require expanding the axtree's (or syncing) performance or behavior beyond what is required for a11y purposes.
Yeah, I'm not sure if I can be a good judge of this, so do please LMK if that's the case.
Specifically, I think it is early enough that I don't know if I can answer these questions:
Sam, when you're even kind of sure that you're going to introduce a new <login> element, file an issue on https://github.com/w3c/html-aam/issues/ asking for ARIA's guidance for mappings for this new element. (Are you already kind of sure? If so, go ahead and file.)I think it is plausible that this <login> element will behave more like the <geolocation> element more than <search> or <main>, so I wanted to make sure that I have something that I can play with without cornering myself.
Can you help me understand something? Will this CL actually have any affect on screen readers? Like, if a user runs into a website with a <login> element, with this CL patched in, will their user experience change in any shape or form?
If so, I think this is probably not the right approach to this problem.
I'm wondering, for example, if I'm better off calling rfh->ExecuteJavaScriptInIsolatedWorld() instead from the browser process at run time, rather than using the accessibility tree:
https://chromium-review.googlesource.com/c/chromium/src/+/7536484
WDYT?
That seems a lot less invasive to the accessibility codebase and might allow me to satisfy my basic requirement to help agentic browsing to find these when they need it?
WDYT?
Related details
- David Grogan
- Philip Jägenstedt
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |