a11y: Introductory notice missing for changing context

Working on it.

Created the MR !9.

Installed the module. I tried to place the Admin Feedback Block but got some Js error. Moving it to Needs Work.

Checked again, works fine for me @koustav_mondal. Please check the branch once and the specific drupal version for it.

Sorry for the confusion. Chceked again. Attaching videos for this. LGTB+

Thanks for the improvement!
I'm not an a11y pro but I think this might not be enough. As stated in the original description, screen readers would not know the DOM has changed otherwise. Sorry for not providing these additional details initially.

Gathering from https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attribut..., I think the new introductory text should be wrapped in something like this:
<div role="alert" aria-live="assertive" aria-atomic="true" id="feedback-live-region" class="sr-only"></div>

However, sr-only is bootstrap only, and, depending on the theme used, other classes might be necessary.
I'm OK with showing this message to everyone, but maybe there are use cases where this should only be shown to impaired users.

Do you know of a standardized way in Drupal to style screenreader-only elements?
A checkbox in the config to enable this would be enough, then. I'm just a sysadmin, sorry I can't provide any more info here..

A more general approach would be to define a configurable CSS class, so admins can easily set one that gets used in the theme.
(I know styling via an id would be an option, too, but using a class is easier and defining a custom class for an element is used in e.g. views as well, so it is a rather known concept in Drupal already).

See 🐛 A11y: aria-label approach to improve label accessibility, remove hardcoded heading levels Active . The DOM-update case seems to fixed there.
Building on that and thanks to your code I can now see where to adapt things.

I'll attach a little patch just for showing this introductory text. However, it builds upon the other mentioned issue, so I don't want to create a MR yet (but can do so once it is merged).

Please test with

"drupal/admin_feedback": {
    "Improve a11y": "https://git.drupalcode.org/project/admin_feedback/-/merge_requests/10.patch",
    "Add intro text": "patches/admin_feedback_intro_text.patch"
},

for the time being.

I just happened upon this issue.

A relatively simple solution for this is to use Drupal.announce() → to speak an meaningful message describing what happened when the markup change completes (probably this would work best at the end of the big click handler, but I'm not familiar enough with the module's javascript to be positive).

We've used this successfully in applications where an action changes something not immediately following the button/form-control that triggered the action, like, e.g., a "Close all accordions" button: Drupal.announce(Drupal.t('All accordions closed.'));

I looked into this a bit more and consulted a colleague.

Based on his comments and a bit more testing, I think the bigger issue may be that the buttons are removed from the DOM at all. It raises a couple of problems:

• what even could we say to explain "the button you just clicked is now gone, but please carry on"?
• (more importantly), where does focus go?

But leaving them in place solves both issues fairly simply (along with letting a user change their mind after having clicked a button in error).

I've not been able to physically test and inspect the behaviour, so the following is based solely on above conversation and the module source code.

My worries around the disappearing Yes / No buttons in general would be:
- Failure of WCAG 3.2.2 On Input: as unexpected event
- Issue with regards WCAG 2.1.1 Keyboard with focus being lost (probably returns to beginning of page) on input
- Inability/confusion for user to be aware of or modify their selection

If the buttons (or radio inputs ideally, even if styled as buttons) remain visible and changeable, there would technically be no need to specifically announce anything as no hijacking of user's focus and the feedback form would appear in (logical) subsequent tab order, and therefore no longer a change in context.

There is no harm in having informative text on what will happen however on feedback type selection , so the work so far is still relevant.