Remove it and use proper API instead as outlined in https://github.com/fomantic/Fomantic-UI/issues/1332#issuecomment-588079479.
Alternative: Just remove it and wait on Fomantic to provide the a11y hints eventually (My favorite).
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.
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.
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.
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 - 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?
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
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.
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.
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.
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.
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 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
—
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.
I can probably to a minimal-effort compatibilty for the current ones but nothing more.
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.
Most helpful comment
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.