I like this but looks like we're going to have to fix some tests :/

Do you want to do it, or shall I give it a try?

Hm, I need some help understanding this:

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-hidden_attribute says:

Adding aria-hidden="true" to an element removes that element and all of its children from the accessibility tree. This can improve the experience for assistive technology users by hiding:
    [...]
    offscreen or collapsed content, such as menus

which applies to this line here, but how does the user access the menu (and its buttons) then?

I like this but looks like we're going to have to fix some tests :/

Do you want to do it, or shall I give it a try?

I think an explanation of how the tests work for testing UI would be helpful for me to attempt to do it first.

Reading the last "note" on https://www.w3.org/TR/using-aria/#4thrule since these entries are hidden by default (using display: none;, if I understand correctly we shouldn't need to add aria-hidden="true" here, no?

I like this but looks like we're going to have to fix some tests :/

Do you want to do it, or shall I give it a try?

I think an explanation of how the tests work for testing UI would be helpful for me to attempt to do it first.

The test suite is practically closer to an integration test suite than unit-tests, so in the UI or API tests we test end to end, from the HTTP request to the DB and back. Therefore a number of tests check the HTML return to ensure the right page is returned or for the presence of key elements in that page.

Hm, I need some help understanding this:

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-hidden_attribute says:
Adding aria-hidden="true" to an element removes that element and all of its children from the accessibility tree. This can improve the experience for assistive technology users by hiding: [...] offscreen or collapsed content, such as menus
which applies to this line here, but how does the user access the menu (and its buttons) then?

The aria-hidden here serves to make the screen reader skip trying to read an icon's ::before and skip straight to the content.

Bootstrap seems to automatically manage the menu's a11y state.

When I navigate through the page and hit on an entry that toggles a menu, my screen reader says the current state of the menu (open or closed). I can then interact to toggle the menu, which will show up in the a11y focus chain as I proceed to head forwards and backwards in it. When I go back to the entry and toggle again, the menu is removed from the a11y focus chain.

Adding aria-hidden="true" to an element removes that element and all of its children from the accessibility tree. This can improve the experience for assistive technology users by hiding:
[...]
offscreen or collapsed content, such as menus
````
which applies to this line here, but how does the user access the menu (and its buttons) then?

The aria-hidden here serves to make the screen reader skip trying to read an icon's ::before and skip straight to the content.

Bootstrap seems to automatically manage the menu's a11y state.

When I navigate through the page and hit on an entry that toggles a menu, my screen reader says the current state of the menu (open or closed). I can then interact to toggle the menu, which will show up in the a11y focus chain as I proceed to head forwards and backwards in it. When I go back to the entry and toggle again, the menu is removed from the a11y focus chain.

Many thanks for this explanation, helps me a lot :)

This project has moved to https://forge.fedoraproject.org/apps/pagure. As part of the migration, all open pull requests on pagure.io have been closed. If you'd like to continue working on this, please fork the repository on the new forge and re-submit your PR there.