Missing 'aria-expanded' attribute in 'Customize' button

Following up this issue. Can it be remedied in Drupal, or is this related to https://github.com/klaro-org/klaro-js/issues/100 ?

We can add the aria-expanded="false" via JS in Drupal. But we cannot change this state because after clicking the whole markup is removed from DOM. Does it still make sense to use this aria attribute?

We still need to change the state to aria-expanded="true" after clicking. This is related to the klaro-js library then, as @svenryen commented.
I will follow up there.

I am not sure if aria-expanded would be my attribute of choice here. aria-expanded is usually associated with expanding and collapsing elements in close proximity to the toggle button. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Referenc... also lists the option of elements displayed or hidden, but still aria-expanded is more associated with cases like a details element and the expanded or collapsed summary element- where both are in close proximity.

in this case you have a dialog modal that is displayed in the center of the visual viewport, not in close proximity to the link/button in the bottom right corner. at the moment klarojs hasnt set up the dialog modal properly, it has neither an aria-modal attribute nor is using a dialog element (something we wanted to propose upstream in the klarojs queue on github). so at the moment a screenreaderuser would have the aria-expanded="true" attribute accessible (but it is not anywhere near in close proximity in the dom), but as soon as the aria-modal attribute would be in place or the dialog modal is being used, everything outside the dialog modal element is being excluded from the accessibility object model (AOM) and in consequence the aria-expanded="true" would be unavailable and inaccessible.

my preferred attribute of choice in this scenario would be the aria-haspopup="dialog". that way, if a user is getting the customize link/button into focus the aural interface would be Customize, dialog pop up, button. that way it would be crystal clear to the user that by pressing that link/button a dialog modal would open up. the expectations would be set in a very clear manner. a page for testing the attribute can be found here: https://a11ysupport.io/tests/html/aria/aria-haspopup_examples.html ... the support isn't 100% yet, there is an older overview https://a11ysupport.io/tech/aria/aria-haspopup_attribute as well as a more recent writeup here https://www.matuzo.at/blog/2023/aria-haspopup/ - in general it is good but the main offenders with only partial and or lacking support are narrator and talkback

i've discussed the topic with @mgifford and he agreed to my points, his only worry was also that the support for certain screenreaders is not perfect yet. at the end he added: "We are always working to the future with work on Core. aria-haspopup will get better support"

p.s. but would probably the best choice to make those changes in regard of aria-haspopup as well as aria-modal/dialog element upstream on the klarojs queue

Thank you for feedback, rkoller. We have the Klaro! button "Manage consents" which already has the attribute aria-haspopup="dialog". I would also add this attribute to the "customize"-button. I would also add type="button".

I am not able to add any attribute when the consent-dialog is open - because the notice is removed from DOM.

Please feedback and I will start.