Remove/Replace custom version of semantic dropdown

[silverwind]

Remove it and use proper API instead as outlined in fomantic/Fomantic-UI#1332 (comment).

[silverwind]

Alternative: Just remove it and wait on Fomantic to provide the a11y hints eventually (My favorite).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[Flameborn]

Removing this and waiting for Fomantic to implement it upstream would mean that Gitea's dropdowns are going to break for screen reader users.

If you choose to do this, and I hope you don't until Fomantic implements it, you should mention it in the changelog to warn existing screen reader users, of which there are quite a few at the moment.

[zeripath]

So unfortunately I think that this piece of code may be attempting to do too much. If we can restructure it to not require so much insertion to fomantics code that would be much better - even if it requires us to set extra attributes in our templates that's still better.

Can anyone get fomantic/Fomantic-UI#1332 to just work for a very simple page?

As with everything we need to split things down into simple steps.

[Jookia]

I don't want to sound salty but I provided a patch series implementing dropdown accessibility in simple steps when I originally added the code. As for whether it's too much, it doesn't implement half the functionality needed for drop down accessibility given the wide variety of widgets Gitea uses.

I feel quite confident saying that you cannot implement accessible dropdowns using that API they've provided, and perhaps not with Fomantic at all. To implement ARIA support you need a concept of widgets which Fomantic lacks, instead it ships low-level components that you compose together in various ways in HTML.

[zeripath]

@Jookia - I never intended to dismiss your work. My only worry is that it walks the DOM and recreates things in a way that potentially breaks.

I've spent hours trying to get orca to work and failed. I've tried to find any information on what needs to change to make this work and have failed.

It must be possible to make dropdowns work properly. Can anyone just give us an example of something that actually works?

[Jookia]

My code works for dropdown menus, the GitHub widgets are fully accessible. If Orca isn't working on your distro you might want to try another distro or NVDA on Windows.

…

On Tue, May 19, 2020 at 01:42:36PM -0700, zeripath wrote: @Jookia - I never intended to dismiss your work. My only worry is that it walks the DOM and recreates things in a way that potentially breaks. I've spent hours trying to get orca to work and failed. I've tried to find any information on what needs to change to make this work and have failed. It **must** be possible to make dropdowns work properly. Can anyone just give us an example of something that actually works? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #10672 (comment)

[Flameborn]

Screen reader implementation may differ from platform to platform, even from browser to browser. I have tested Gitea’s dropdowns via VoiceOver/Safari under MacOS, and under Windows via NVDA. Both of them seem to work, at least the items can be accessed, as well as arrow-key-navigation works as expected. The problem is that as @Jookia mentions here fomantic/Fomantic-UI#1332 <fomantic/Fomantic-UI#1332>, the implementation of a single component can be quite diverse, so this makes it quite hard to add accessibility. This is the only one implementation I know of that is usable with a screen reader. Anywhere else, e.g. when using Gogs, dropdowns are completely inaccessible under MacOS as the items are not reachable, on Windows you need to turn off styles to expose everything on the page, which is a mess.

…

On 2020. May 20., at 6:10, Jookia ***@***.***> wrote: My code works for dropdown menus, the GitHub widgets are fully accessible. If Orca isn't working on your distro you might want to try another distro or NVDA on Windows. On Tue, May 19, 2020 at 01:42:36PM -0700, zeripath wrote: > @Jookia - I never intended to dismiss your work. My only worry is that it walks the DOM and recreates things in a way that potentially breaks. > > I've spent hours trying to get orca to work and failed. I've tried to find any information on what needs to change to make this work and have failed. > > It **must** be possible to make dropdowns work properly. Can anyone just give us an example of something that actually works? > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > #10672 (comment) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10672 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4EEUS2TCXOH6H5AJBLRSNJZ7ANCNFSM4LD3G2EQ>.

[Jookia]

Editing the DOM to add roles is a hack, but editing the DOM to update aria labels isn't. In theory what should happen is each UI element in HTML should be assigned a role and be updated to be nested with certain elements, Fomantic should provide the ability to set ARIA properties and handle keypresses then Gitea should at runtime hook the components to bring things together. In reality this would be a nightmare to do if you aren't an ARIA expert since there's so many ways to do it wrong. I'm not even sure the way I patched it is right. Dropdowns can sometimes be listboxes, sometimes they can be search menus that autocomplete, but sometimes they can also include elements inside them like tags as a list. You would have to handle focus between elements, figure out what keybindings should work, handle the focus ring and test it on actually disabled people to see if they can understand what's happening. My conclusion that while it's possible to make Gitea's UI accessible, it's a large and complex amount of work that very few people would understand or even test. If a dropdown menu is too much, just think about dropdown menus that include other widgets! Having to put HTML in each page and check it works is also a headache and error prone. You have to test every page with every setting just to see if it works on every device. You should have a set of widgets that do boring things then put them all on a page to test at once. At the moment Gitea seems to be putting the responsibility for accessibility on Fomantic since it provides components and Fomantic seems to be putting responsibility for accessibility on Gitea since Gitea builds widgets out of those components. Regardless of who's responsiblity it is, things aren't improving. I think Gitea should take on responsibility for the accessiblity of its code base and not wait for Fomantic. Fomantic doesn't ship UIs to people with the aim of being accessible. Gitea needs to work out its widget problem and write accessibility code, even if that means changing UI toolkits to something that provides accessibility options. I really don't want this to come across as a rant or attack, just my observation about how things are now. I don't care about the past since we can't change it, but I think Gitea needs to make decisions about its future and whether people with disabilities are part of that.