-
Notifications
You must be signed in to change notification settings - Fork 140
core aam roles known entries #2682
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
core aam roles known entries #2682
Conversation
- 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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. |
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 |