Conversation
dtsengchromium
commented
Nov 25, 2025
dtsengchromium
commented
- Add initial Android mappings
- [core-aam]: fill in known Android role mappings
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
cyns
left a comment
cyns
left a comment
There was a problem hiding this comment.
Great start!
I noticed that a lot of roles map to android.view.View. Is this sufficient to express their semantics and behavior? Similarly, is GridView sufficient to express the semantics of a data table using the table role?
|
Thanks! This can be a topic at the next wg meeting and I can try to attend
and help fill the group in on the general effort.
tl;dr mappings to
android.view.View
reflect the current usage in Chrome.
As background, classnames represent existing Android widgets. This can be
anything from the Android sdk or perhaps beyond. The widget itself defines
the more granular details of how the "role" works on Android.
For cases where we have no mapping or no closest match, we may default to
android.view.View
which at least surfaces a base level of support and interpretation by ATs.
For the specification process, we can also default to
android.view.View
or simply leave as
TBD
if the group prefers.
…On Thu, Dec 4, 2025 at 11:00 AM Cynthia Shelly ***@***.***> wrote:
***@***.**** commented on this pull request.
Great start!
I noticed that a lot of roles map to android.view.View. Is this sufficient
to express their semantics and behavior? Similarly, is GridView sufficient
to express the semantics of a data table using the table role?
—
Reply to this email directly, view it on GitHub
<#2682 (review)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADLR7MFGODWNWORKWRIZ2F34ACAD7AVCNFSM6AAAAACNGFABQOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTKNBRGYYTMMJWGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
@dtsengchromium Can you please fix the conflicts here? It's probably just a matter of accepting what is currently on this branch, it's just that since we merged #2681 we created the conflicts. |
dtsengchromium
force-pushed
the
core-aam-roles-known-entries
branch
from
a2941bf to
5009609
Compare
|
@daniel-montalvo I'm not sure how the merge was done. I've tried to see the conflicts by syncing the branch, editing its upstream, etc. I'd rather not have to go through the web UI if possible since this should have been a clean merge. I'm also wondering if there's a preferred workflow the group is used to. I probably should have just created one pr since it looks like these changes are not being merged to main. |
dtsengchromium
force-pushed
the
core-aam-roles-known-entries
branch
from
faf923a to
1cbca6e
Compare
|
That looks to have fixed the conflict. Please take another look. Still curious about preferred workflows. |
|
Looking great now @dtsengchromium Thanks! |
|
The ARIA Working Group just discussed The full IRC log of that discussion<jamesn> topic: core aam roles known entries https://github.com//pull/2682 [from agendabot]<jamesn> github: https://github.com//pull/2682 <pkra> giacomo-petri: related to the WPT, I had a question about UAs not following the suggestion on presentational children. <pkra> jcraig: the PR I merged was on SVG. So nothing happened on that. <pkra> spectranaut_: we'll agenda the other one for next year. <pkra> spectranaut_: David Tseng has been adding the core-aam mappings for Android. <pkra> ... this included frontmatter and a bit of TBD entries <pkra> dtseng: over the past year there's been a renewed effort to enhance and extend the android AAPIs <pkra> ... there is more work ahead. The initial round is coming to Android SDKs <pkra> ... the PR adds the initial parts of this, in particular how Android tackles roles <pkra> .. it's mostly mapped to existing Android widgets. <pkra> ... we have mappings for some existing APIs which I'll try to add. Some more hopefully incoming. <spectranaut_> https://deploy-preview-2682--wai-aria.netlify.app/core-aam/ <pkra> spectranaut_: thank you! FYI for everyone, the PR has a deploy link but the links need adjustments to reach the child specs <pkra> ... the PR has some reviewers <pkra> mattking: maybe the correct links could be added to the top card? <pkra> Daniel: yes, I need to get to automate that. <jarhar> the whatwg/html spec has this when you create a PR there, it automatically edits the PR description and adds links to the previews of the modified files <pkra> spectranaut_: are there more reviewers? <pkra> ... is there a particular kind of feedback you're hoping for, david? <pkra> ... My assumption is that you're the experts and this documents the status quo and should be merged. <pkra> dtseng: review would help, using the experience of the ARIA group. <pkra> ... also on the API level. <spectranaut_> q? <pkra> ... I think we can discover a lot from the review. <pkra> ... I want to mention that some things are trickier. E.g. accessible name doesn't have an equivalent. We have content description, labelledby etc. We have discussed this internally but having insights from this group would be very useful. <pkra> ... all the tricky things that this group has dealt with will help. E.g. overriding, concatenating or not |
Hi @dtsengchromium, sorry for the late reply, I finally looked at this PR more closely. About this question -- I'm curious, are there some roles in ARIA that you think will always map to android.view.View? Roles for which android.view.View is actually the correct mapping? It sounds like in at least some cases it is a stopgap. As for the AAM, I would say, if Android currently maps the role to android.view.View, then that is what we should have in the AAM. If it is generally or always a stopgap, we could have a note somewhere that says something about android.view.View being a stopgap in some cases, explaining why, and explaining that that mapping may change. That could belong in the android summary section or maybe even the Exposing attributes that do not directly map to accessibility API properties section. Also, I'm curious, for things that map to If the answer is yes, then I think we should only land things in the AAM that have a full description of everything a implementer would need to expose for a core-aam role to be accessible, including these attributes. If the class alone is sufficient, then we can land those. |
7 participants
