Remove/Replace custom version of semantic dropdown #5027

@silverwind commented on GitHub (Mar 8, 2020):

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

@silverwind commented on GitHub (Mar 8, 2020): Alternative: Just remove it and wait on Fomantic to provide the a11y hints eventually (My favorite).

GiteaMirror commented

@stale[bot] commented on GitHub (May 7, 2020):

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.

@stale[bot] commented on GitHub (May 7, 2020): 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.

GiteaMirror commented

@Flameborn commented on GitHub (May 19, 2020):

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.

@Flameborn commented on GitHub (May 19, 2020): 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.

GiteaMirror commented

@zeripath commented on GitHub (May 19, 2020):

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 https://github.com/fomantic/Fomantic-UI/issues/1332 to just work for a very simple page?

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

@zeripath commented on GitHub (May 19, 2020): 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 https://github.com/fomantic/Fomantic-UI/issues/1332 to just work for a very simple page? As with everything we need to split things down into simple steps.

GiteaMirror commented

@Jookia commented on GitHub (May 19, 2020):

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.

@Jookia commented on GitHub (May 19, 2020): 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.

GiteaMirror commented

@zeripath commented on GitHub (May 19, 2020):

@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?

@zeripath commented on GitHub (May 19, 2020): @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?

GiteaMirror commented

@Jookia commented on GitHub (May 20, 2020):

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:
https://github.com/go-gitea/gitea/issues/10672#issuecomment-631071213

@Jookia commented on GitHub (May 20, 2020): 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: > https://github.com/go-gitea/gitea/issues/10672#issuecomment-631071213

GiteaMirror commented

@Flameborn commented on GitHub (May 20, 2020):

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 https://github.com/fomantic/Fomantic-UI/issues/1332 https://github.com/fomantic/Fomantic-UI/issues/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 notifications@github.com 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:
https://github.com/go-gitea/gitea/issues/10672#issuecomment-631071213
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/10672#issuecomment-631224362, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4EEUS2TCXOH6H5AJBLRSNJZ7ANCNFSM4LD3G2EQ.

@Flameborn commented on GitHub (May 20, 2020): 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 https://github.com/fomantic/Fomantic-UI/issues/1332 <https://github.com/fomantic/Fomantic-UI/issues/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 <notifications@github.com> 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: > > https://github.com/go-gitea/gitea/issues/10672#issuecomment-631071213 > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/10672#issuecomment-631224362>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4EEUS2TCXOH6H5AJBLRSNJZ7ANCNFSM4LD3G2EQ>. >

GiteaMirror commented

@Jookia commented on GitHub (May 20, 2020):

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.

@Jookia commented on GitHub (May 20, 2020): 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.

GiteaMirror commented

@silverwind commented on GitHub (Aug 1, 2020):

So I've been recently testing dropdowns using Apple's VoiceOver reader and I could not get cursor navigation to work at all unless I selected a item and reopened the dropdown. It's just a completely broken mess in terms of a11y.

Fomantic UI in itself is a non-accessible framework and it's a hopeless effort trying to fix that. It's rotten to the core, so to say.

Time would be much better invested to switch to a different framework that has a11y at its core but I estimate it'd be at least 1000 hours of work to do so.

I'll remove the dropdown.js override.

@silverwind commented on GitHub (Aug 1, 2020): So I've been recently testing dropdowns using Apple's VoiceOver reader and I could not get cursor navigation to work at all unless I selected a item and reopened the dropdown. It's just a completely broken mess in terms of a11y. Fomantic UI in itself is a non-accessible framework and it's a hopeless effort trying to fix that. It's rotten to the core, so to say. Time would be much better invested to switch to a different framework that has a11y at its core but I estimate it'd be at least 1000 hours of work to do so. I'll remove the dropdown.js override.

GiteaMirror commented

@Flameborn commented on GitHub (Aug 1, 2020):

The fix is not perfect, and I, too, vote for swapping out Semantic/Fomantic UI, when possible.

In its current state, the dropdowns can be used with a screen reader via the keyboard. Removing the override will make this impossible, i.e. Gitea will be unusable again (since Dropdowns are part of the UI even when creating a repository.

On 2020. Aug 1., at 18:11, silverwind notifications@github.com wrote:

So I've been recently testing dropdowns using Apple's VoiceOver reader and I could not get cursor navigation to work at all unless I selected a item and reopened the dropdown. It's just a completely broken mess in terms of a11y.

Fomantic UI in itself is a non-accessible framework and it's a hopeless effort trying to fix that. It's rotten to the core, so to say.

Time would be much better invested to switch to a different framework that has a11y at its core but I estimate it'd be at least 1000 hours of work to do so.

I'll remove the dropdown.js override.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/10672#issuecomment-667553665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4GD7NATEYM6KL3AFVLR6Q5BPANCNFSM4LD3G2EQ.

@Flameborn commented on GitHub (Aug 1, 2020): The fix is not perfect, and I, too, vote for swapping out Semantic/Fomantic UI, when possible. In its current state, the dropdowns can be used with a screen reader via the keyboard. Removing the override will make this impossible, i.e. Gitea will be unusable again (since Dropdowns are part of the UI even when creating a repository. > On 2020. Aug 1., at 18:11, silverwind <notifications@github.com> wrote: > > > So I've been recently testing dropdowns using Apple's VoiceOver reader and I could not get cursor navigation to work at all unless I selected a item and reopened the dropdown. It's just a completely broken mess in terms of a11y. > > Fomantic UI in itself is a non-accessible framework and it's a hopeless effort trying to fix that. It's rotten to the core, so to say. > > Time would be much better invested to switch to a different framework that has a11y at its core but I estimate it'd be at least 1000 hours of work to do so. > > I'll remove the dropdown.js override. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/10672#issuecomment-667553665>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4GD7NATEYM6KL3AFVLR6Q5BPANCNFSM4LD3G2EQ>. >

GiteaMirror commented

@silverwind commented on GitHub (Aug 1, 2020):

I guess some MutationObserver-based hack can be done to add the attributes on the fly at runtime.

From my testing, this modification we have only works on one specific kind of dropdown (not the <select> style one seen on new repo page for example), so it's rather limited.

@silverwind commented on GitHub (Aug 1, 2020): I guess some `MutationObserver`-based hack can be done to add the attributes on the fly at runtime. From my testing, this modification we have only works on one specific kind of dropdown (not the `<select>` style one seen on new repo page for example), so it's rather limited.

GiteaMirror commented

@Flameborn commented on GitHub (Aug 1, 2020):

You are right, the dropdown does not work everywhere, but where it does, something should be used so that we would not lose access, however limited it may be, if you choose to remove the override.

If in turn, this can fix the new-style dropdowns as well, it’s definitely a bonus.

On 2020. Aug 1., at 18:39, silverwind notifications@github.com wrote:

I guess some MutationObserver-based hack can be done to add the attributes on the fly at runtime.

From my testing, this modification we have only works on one specific kind of dropdown (not the style one seen on new repo page for example), so it's rather limited. — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/10672#issuecomment-667557286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4FQGR64L65NOGDFHZTR6RANVANCNFSM4LD3G2EQ.

@Flameborn commented on GitHub (Aug 1, 2020): You are right, the dropdown does not work everywhere, but where it does, something should be used so that we would not lose access, however limited it may be, if you choose to remove the override. If in turn, this can fix the new-style dropdowns as well, it’s definitely a bonus. > On 2020. Aug 1., at 18:39, silverwind <notifications@github.com> wrote: > > > I guess some MutationObserver-based hack can be done to add the attributes on the fly at runtime. > > From my testing, this modification we have only works on one specific kind of dropdown (not the <select> style one seen on new repo page for example), so it's rather limited. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/10672#issuecomment-667557286>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4FQGR64L65NOGDFHZTR6RANVANCNFSM4LD3G2EQ>. >

GiteaMirror commented

@silverwind commented on GitHub (Aug 1, 2020):

I can probably to a minimal-effort compatibilty for the current ones but nothing more.

@silverwind commented on GitHub (Aug 1, 2020): I can probably to a minimal-effort compatibilty for the current ones but nothing more.

GiteaMirror commented

@Flameborn commented on GitHub (Aug 1, 2020):

That’s good enough, thank you.

On 2020. Aug 1., at 19:13, silverwind notifications@github.com wrote:

I can probably to a minimal-effort compatibilty for the current ones but nothing more.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/10672#issuecomment-667561400, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4CNBLT735E2JB3PGUDR6RENNANCNFSM4LD3G2EQ.

@Flameborn commented on GitHub (Aug 1, 2020): That’s good enough, thank you. > On 2020. Aug 1., at 19:13, silverwind <notifications@github.com> wrote: > > > I can probably to a minimal-effort compatibilty for the current ones but nothing more. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/10672#issuecomment-667561400>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4CNBLT735E2JB3PGUDR6RENNANCNFSM4LD3G2EQ>. >

GiteaMirror commented

@henningoschwald commented on GitHub (Feb 13, 2021):

Hi,

I am not deep enough into web development to provide pull requests, but as a blind user of the Orca screenreader on Linux I might be of help anyway.

I just started to use Gitea and found severall accessibility problems, most notably controls not focussable or entirely not usable with the keyboard. One of the biggest issues is the inaccessible drop-downs based on Fomantic, i.e. used to select the database type in the installation screen or to select the license or label set when creating a new repository.

the drop-down is announced as a simple text field, there is no indication that the user has to select from existing values.
I was able to expand the drop-down and display available values by pressing Enter, but this was not announced.
the list of available values then was not associated semantically to the drop-down, the association seems to be entirely visual. I also wasn't able to select from existing values at least the screenreader didn't announce anything when pressing arrow up or down.

The expected behavior would be to have the drop-down announced i.e as combo box or list box by setting the apropriate roles and then selecting from available values using the up and down arrows.

The required steps for making a custom control accessible to screenreader users are explained e.g. in this article. That said, all this would not be needed for native control elements, which can be styled as wanted using CSS and you get screen reader accessibility and keyboard navigation for free.

If there is something for me to test or if there are questions about how a screenreder user interacts with web applications, just ping me.

@henningoschwald commented on GitHub (Feb 13, 2021): Hi, I am not deep enough into web development to provide pull requests, but as a blind user of the Orca screenreader on Linux I might be of help anyway. I just started to use Gitea and found severall accessibility problems, most notably controls not focussable or entirely not usable with the keyboard. One of the biggest issues is the inaccessible drop-downs based on Fomantic, i.e. used to select the database type in the installation screen or to select the license or label set when creating a new repository. - the drop-down is announced as a simple text field, there is no indication that the user has to select from existing values. - I was able to expand the drop-down and display available values by pressing Enter, but this was not announced. - the list of available values then was not associated semantically to the drop-down, the association seems to be entirely visual. I also wasn't able to select from existing values at least the screenreader didn't announce anything when pressing arrow up or down. The expected behavior would be to have the drop-down announced i.e as combo box or list box by setting the apropriate roles and then selecting from available values using the up and down arrows. The required steps for making a custom control accessible to screenreader users are explained e.g. in [this article](https://dev.to/emmabostian/creating-a-custom-accessible-drop-down-3gmo). That said, all this would not be needed for native control elements, which can be styled as wanted using CSS and you get screen reader accessibility and keyboard navigation for free. If there is something for me to test or if there are questions about how a screenreder user interacts with web applications, just ping me.

GiteaMirror commented

@Flameborn commented on GitHub (Feb 13, 2021):

@henningoschwald This is a known issue, see https://github.com/go-gitea/gitea/issues/1263 and https://github.com/go-gitea/gitea/issues/7057

@Jookia Added some accessibility features for dropdowns, as previously the items and the currently selected item was not exposed.

As it stands, switching away from Fomantic is not something that is being considered, as far as I am aware. Reaching out to the Fomantic devs, implementing accessibility is not among their future plans.

@Flameborn commented on GitHub (Feb 13, 2021): @henningoschwald This is a known issue, see https://github.com/go-gitea/gitea/issues/1263 and https://github.com/go-gitea/gitea/issues/7057 @Jookia Added some accessibility features for dropdowns, as previously the items and the currently selected item was not exposed. As it stands, switching away from Fomantic is not something that is being considered, as far as I am aware. Reaching out to the Fomantic devs, implementing accessibility is not among their future plans.

GiteaMirror commented

@wxiaoguang commented on GitHub (May 29, 2022):

I vote for the removal should be done, to make the code maintainable.

Since the customized dropdown had been abandoned, the code was left there unmaintained.

Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself. The accessibility work requires experienced experts and time, however at the moment Gitea doesn't meet that requirement to make the accessibility correct.

@wxiaoguang commented on GitHub (May 29, 2022): I vote for the removal should be done, to make the code maintainable. Since the customized dropdown had been abandoned, the code was left there unmaintained. Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself. The accessibility work requires experienced experts and time, however at the moment Gitea doesn't meet that requirement to make the accessibility correct.

GiteaMirror commented

@Jookia commented on GitHub (May 29, 2022):

I was under the impression that decisions about accessibility-related code are on hold until #16660 is resolved

@Jookia commented on GitHub (May 29, 2022): I was under the impression that decisions about accessibility-related code are on hold until #16660 is resolved

GiteaMirror commented

@wxiaoguang commented on GitHub (May 29, 2022):

I was under the impression that decisions about accessibility-related code are on hold until #16660 is resolved

Glad to know that, let me put these information together.

@wxiaoguang commented on GitHub (May 29, 2022): > I was under the impression that decisions about accessibility-related code are on hold until #16660 is resolved Glad to know that, let me put these information together.

GiteaMirror commented

@Flameborn commented on GitHub (May 29, 2022):

Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself. The accessibility work requires experienced experts and time, however at the moment Gitea doesn't meet that requirement to make the accessibility correct.

I would love to know how you drew this conclusion @wxiaoguang.

Without having access to dropdowns, you can't create a repo, access your profile menu, create new issues, change the site language, etc. Even during installation, you can't change the database type without this added patch. How is this not helping Gitea's accessibility issue?

Accessibility is not something you offload to a UI framework. Yes, it can help you write components that adhere to accessibility standards, but accessibility is a developers, thus Gitea's, responsibility indeed. If you are responsible for writing CSS that displays well on as many devices as possible, why do you think that accessibility is an exception to that?

I understand that implementing proper accessibility requires expertise, but that should not be used as an excuse to throw the issue of accessibility under the table and forget about it.

I am sure that there are lots of screen reader users, myself included, who would be more than willing to help. @Jookia offered to have a discussion, if I recall correctly.

@Flameborn commented on GitHub (May 29, 2022): > Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself. The accessibility work requires experienced experts and time, however at the moment Gitea doesn't meet that requirement to make the accessibility correct. I would love to know how you drew this conclusion @wxiaoguang. Without having access to dropdowns, you can't create a repo, access your profile menu, create new issues, change the site language, etc. Even during installation, you can't change the database type without this added patch. How is this not helping Gitea's accessibility issue? Accessibility is not something you offload to a UI framework. Yes, it can help you write components that adhere to accessibility standards, but accessibility is a developers, thus Gitea's, responsibility indeed. If you are responsible for writing CSS that displays well on as many devices as possible, why do you think that accessibility is an exception to that? I understand that implementing proper accessibility requires expertise, but that should not be used as an excuse to throw the issue of accessibility under the table and forget about it. I am sure that there are lots of screen reader users, myself included, who would be more than willing to help. @Jookia offered to have a discussion, if I recall correctly.

GiteaMirror commented

@wxiaoguang commented on GitHub (May 29, 2022):

@Flameborn

My conclusion comes from that the customized dropdown has been declared as stopped and unmaintained, by the comment of Jookia (https://github.com/go-gitea/gitea/pull/8638#issuecomment-580992118)

From the code health view, unmaintained code should be cleaned up.

@wxiaoguang commented on GitHub (May 29, 2022): @Flameborn My conclusion comes from that the customized dropdown has been declared as stopped and unmaintained, by the comment of Jookia (https://github.com/go-gitea/gitea/pull/8638#issuecomment-580992118) From the code health view, unmaintained code should be cleaned up.

GiteaMirror commented

@Flameborn commented on GitHub (May 29, 2022):

I see. So you mean that if a major feature becomes unmaintained by its original contributor, Gitea should just drop the code, never mind who relies on it.

I classify this as a major feature, because as I mentioned above, Gitea would become completely unusable with a screen reader without it.

@Flameborn commented on GitHub (May 29, 2022): I see. So you mean that if a major feature becomes unmaintained by its original contributor, Gitea should just drop the code, never mind who relies on it. I classify this as a major feature, because as I mentioned above, Gitea would become completely unusable with a screen reader without it.

GiteaMirror commented

@wxiaoguang commented on GitHub (May 29, 2022):

I see. So you mean that if a major feature becomes unmaintained by its original contributor, Gitea should just drop the code, never mind who relies on it.

I classify this as a major feature, because as I mentioned above, Gitea would become completely unusable with a screen reader without it.

It's just a discussion, and I expressed my thoughts about code health according to the history comments. I believe you also understand that the unmaintained code would break one day, unmaintained code is not the answer to a major feature. Remove unmaintained code and implement the feature in a proper way will benefit everyone. I get your points, and I do not think the removal would really be done recently due to it's really in use.

ps: I have a feeling that the customized dropdown could be removed, and use separate (independent) code to attach the aria-xxx attributes and related events.

@wxiaoguang commented on GitHub (May 29, 2022): > I see. So you mean that if a major feature becomes unmaintained by its original contributor, Gitea should just drop the code, never mind who relies on it. > > I classify this as a major feature, because as I mentioned above, Gitea would become completely unusable with a screen reader without it. It's just a discussion, and I expressed my thoughts about code health according to the history comments. I believe you also understand that the unmaintained code would break one day, unmaintained code is not the answer to a major feature. Remove unmaintained code and implement the feature in a proper way will benefit everyone. I get your points, and I do not think the removal would really be done recently due to it's really in use. ---- ps: I have a feeling that the customized dropdown could be removed, and use separate (independent) code to attach the `aria-xxx` attributes and related events.

GiteaMirror commented

@singuliere commented on GitHub (May 29, 2022):

I vote for the removal should be done, to make the code maintainable.

Since the customized dropdown had been abandoned, the code was left there unmaintained.

Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself. The accessibility work requires experienced experts and time, however at the moment Gitea doesn't meet that requirement to make the accessibility correct.

I do not understand your comments.

In this sentence:"Since the customized dropdown had been abandoned, the code was left there unmaintained." it is not possible to figure out if you are referring to something that happened in the past but is not longer true at the present time or if you are referring to the current maintenance state of the code.

In this other sentence "I vote for the removal should be done, to make the code maintainable" is not English and could be interpreted to mean different things.

And finally "Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself." Is a strong and controversial opinion that needs to be articulated with care.

I'm not a native English speaker either so I can appreciate how difficult it is to convey what you mean. It is specially important when you make strong statements like the one you are trying to make. In this case, in order to clarify there is a need to provide examples and links to the code so that the reader can figure out what you mean. For instance, give links to what you consider "scattered customized patches" and explain why.

If you do not make that effort to clarify your meaning, you are forcing the reader to do research in the code history and the code base to narrow down and interpret your sentences, just like a priest would when listening to an oracle. This is not only very difficult to the priest, it is also very likely that what you write will be misunderstood.

@singuliere commented on GitHub (May 29, 2022): > I vote for the removal should be done, to make the code maintainable. > > Since the customized dropdown had been abandoned, the code was left there unmaintained. > > Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself. The accessibility work requires experienced experts and time, however at the moment Gitea doesn't meet that requirement to make the accessibility correct. I do not understand your comments. In this sentence:"Since the customized dropdown had been abandoned, the code was left there unmaintained." it is not possible to figure out if you are referring to something that happened in the past but is not longer true at the present time or if you are referring to the current maintenance state of the code. In this other sentence "I vote for the removal should be done, to make the code maintainable" is not English and could be interpreted to mean different things. And finally "Some scattered customized patches won't change the Gitea's accessibility situation, indeed some accessibility work should be done by low-level frameworks, but not Gitea itself." Is a strong and controversial opinion that needs to be articulated with care. I'm not a native English speaker either so I can appreciate how difficult it is to convey what you mean. It is specially important when you make strong statements like the one you are trying to make. In this case, in order to clarify there is a need to provide examples and links to the code so that the reader can figure out what you mean. For instance, give links to what you consider "scattered customized patches" and explain why. If you do not make that effort to clarify your meaning, you are forcing the reader to do research in the code history and the code base to narrow down and interpret your sentences, just like a priest would when listening to an oracle. This is not only very difficult to the priest, it is also very likely that what you write will be misunderstood.

GiteaMirror commented

@wxiaoguang commented on GitHub (May 29, 2022):

@singuliere

BECAUSE I have ideas about how to remove it (while trying to make the a11zy still work) and before writing the comment I have read many related issue comments in history. I am expressing the situation that the Gitea is facing. And yes I have a strong preference to remove unmaintained code. The fact is code was written and abandoned soon after that.

But you are so aggressive for criticizing, If you can do, please do it, either maintain the customized dropdown and make it work more correctly, or replace it with something else, let me see how can you do the work.

@wxiaoguang commented on GitHub (May 29, 2022): @singuliere BECAUSE I have ideas about how to remove it (while trying to make the a11zy still work) and before writing the comment I have read many related issue comments in history. I am expressing the situation that the Gitea is facing. And yes I have a strong preference to remove unmaintained code. The fact is code was written and abandoned soon after that. But you are so aggressive for criticizing, If you can do, please do it, either maintain the customized dropdown and make it work more correctly, or replace it with something else, let me see how can you do the work.

GiteaMirror commented