Fix ARIA issues on Navbar and Edit menu found via Pa11y / axe

[bram-atmire]

References

• Fixes ARIA issues on navbar and edit menu found via Pa11y / axe #5639
• References ARIA edit menu error on community and item pages #5488
• Builds on fix #5488: add ARIA labeling to hide edit menu from screen readers wh… #5514 (also referencing ARIA edit menu error on community and item pages #5488), which addresses the empty/hidden role="menubar" case in dso-edit-menu. This PR is complementary; both can merge to fully close ARIA edit menu error on community and item pages #5488.

Description

Fix the four remaining ARIA bugs from the WAVE / Pa11y / axe findings on #5488 that #5514 does not cover.

Instructions for Reviewers

List of changes in this PR:

1. src/app/shared/auth-nav-menu/auth-nav-menu.component.html — login dropdown trigger.

   • Was: aria-haspopup="menu" on the button, but the popup it controls is a <div role="dialog" aria-modal="true">. Screen readers announced "has popup, menu" then revealed a dialog.
   • Now: aria-haspopup="dialog". Also dropped the redundant role="button" / tabindex="0" on a real <button> and added an explicit type="button".

2. src/app/navbar/expandable-navbar-section/expandable-navbar-section.component.html — top-level navbar section toggler.

   • Was: <a href="javascript:void(0);" role="menuitem">.
   • Now: <button type="button" role="menuitem">. The navbar wrapper has role="menubar" (navbar.component.html), so the menuitem nesting is valid; the only issue was the href="javascript:void(0)" antipattern. A small SCSS reset (expandable-navbar-section.component.scss) keeps the button looking like the previous anchor (no native button chrome).

3. src/app/header/context-help-toggle/context-help-toggle.component.html — header help button.

   • Was: <a href="javascript:void(0);" role="menuitem">. This control is not nested in any role="menu" / role="menubar" , so its role="menuitem" was an orphan, flagged by axe (aria-required-parent).
   • Now: a plain <button type="button"> with no role attribute. Added a small SCSS reset for the same reason as above.

4. src/app/shared/dso-page/dso-edit-menu/dso-edit-menu-section/dso-edit-menu-section.component.html — each rendered section button under role="menubar".

   • Was: the descendant <a class="btn"> / <button class="btn"> had no role. axe's aria-required-children fires on the parent menubar.
   • Now: each rendered control declares role="menuitem".

Specs were updated for each component:

• auth-nav-menu.component.spec.ts asserts the login toggle has aria-haspopup="dialog".
• expandable-navbar-section.component.spec.ts asserts the toggler is a real <button type="button" role="menuitem">.
• context-help-toggle.component.spec.ts asserts the toggle is a <button type="button"> with no orphan role.
• dso-edit-menu-section.component.spec.ts asserts the rendered control declares role="menuitem".

How to test:

1. Start the UI (yarn start or pm2 start config/dspace-ui-test.json).
2. With a screen reader (VoiceOver, NVDA), focus the navbar Login trigger - announcement should say "has popup, dialog" rather than "menu".
3. Tab to a top-level expandable navbar section ("Browse" by default). The element should be a button (right-click → Inspect to confirm <button type="button">); pressing Enter / Space / ArrowDown still toggles / activates the dropdown.
4. Visit /info/accessibility, focus the context-help icon in the header. Inspect: it should be a <button>, not an anchor.
5. As a logged-in admin, visit any item or community page that renders the dso-edit-menu (<div role="menubar">). Inspect each section's icon button - it should declare role="menuitem".
6. npm run test -- --include='src/app/shared/auth-nav-menu/auth-nav-menu.component.spec.ts' --include='src/app/navbar/expandable-navbar-section/expandable-navbar-section.component.spec.ts' --include='src/app/header/context-help-toggle/context-help-toggle.component.spec.ts' --include='src/app/shared/dso-page/dso-edit-menu/dso-edit-menu-section/dso-edit-menu-section.component.spec.ts' shows 37 specs pass.
7. Re-run axe / Pa11y on a community page, an item page, the login form, and /info/accessibility. The aria-haspopup="menu" on login button, aria-required-parent on the help toggle, and the aria-required-children on the visible dso-edit-menu should all clear.

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (10 files, 56 insertions, 13 deletions).
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. (n/a - no method changes)
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations. (existing keys retained)
• My PR includes details on how to test it.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation. (n/a)
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself. (n/a)
• If my PR fixes an issue ticket, I've linked them together.

[GauravD2t]

Thanks @bram-atmire ! I have thoroughly tested all the steps outlined in the review instructions, and everything is working perfectly as expected.