Screenreaders unable to read Gitea&#39;s various dropdowns #3384

@lunny commented on GitHub (May 28, 2019):

We may need a integration tests with https://github.com/GNOME/orca, that need a orca docker image and drone plugin.

@lunny commented on GitHub (May 28, 2019): We may need a integration tests with https://github.com/GNOME/orca, that need a orca docker image and drone plugin.

GiteaMirror commented

@dpy013 commented on GitHub (Jun 2, 2019):

We may need a integration tests with https://github.com/GNOME/orca, that need a orca docker image and drone plugin.
orca docker image How's it going?

@dpy013 commented on GitHub (Jun 2, 2019): > We may need a integration tests with https://github.com/GNOME/orca, that need a orca docker image and drone plugin. orca docker image How's it going?

GiteaMirror commented

@xogium commented on GitHub (Oct 11, 2019):

Hi,
any news on this ? I spent days installing gitea only to realize that it is practically unusable. Some time I can get away with things by disabling syiling for web pages, some times I have to reenable it again to perform some other action, some times neither of those help. Really a huge disapointment on the sementic ui side and quite one for gitea as well... I'd be happy to test out things with orca since it is my daily driver...

@xogium commented on GitHub (Oct 11, 2019): Hi, any news on this ? I spent days installing gitea only to realize that it is practically unusable. Some time I can get away with things by disabling syiling for web pages, some times I have to reenable it again to perform some other action, some times neither of those help. Really a huge disapointment on the sementic ui side and quite one for gitea as well... I'd be happy to test out things with orca since it is my daily driver...

GiteaMirror commented

@lafriks commented on GitHub (Oct 11, 2019):

It's large task to rewrite all UI to other library but apart from few experiments not much have been done in this direction currently. We would probably also need a designer as well so that such rewrite would result also in better UI for everyone :)

@lafriks commented on GitHub (Oct 11, 2019): It's large task to rewrite all UI to other library but apart from few experiments not much have been done in this direction currently. We would probably also need a designer as well so that such rewrite would result also in better UI for everyone :)

GiteaMirror commented

https://github.com/Semantic-Org/Semantic-UI/issues/348
https://github.com/gogs/gogs/issues/3340
https://github.com/go-gitea/gitea/issues/1263

@Jookia commented on GitHub (Oct 12, 2019):

Wow, this is a damn rabbit hole of issues. The most important I've seen have been:

and mine from yesterday: https://github.com/go-gitea/gitea/issues/8460

I'm seeing two immediate issues for personal use:

Some elements can only be clicked with a mouse
Some elements (dropdown boxes for example) can't be seen properly by screen readers

I'm going to see how hard these are to do a crude local fix for this week.

@Jookia commented on GitHub (Oct 12, 2019): Wow, this is a damn rabbit hole of issues. The most important I've seen have been: https://github.com/Semantic-Org/Semantic-UI/issues/348 https://github.com/gogs/gogs/issues/3340 https://github.com/go-gitea/gitea/issues/1263 and mine from yesterday: https://github.com/go-gitea/gitea/issues/8460 I'm seeing two immediate issues for personal use: 1. Some elements can only be clicked with a mouse 2. Some elements (dropdown boxes for example) can't be seen properly by screen readers I'm going to see how hard these are to do a crude local fix for this week.

GiteaMirror commented

@zeripath commented on GitHub (Oct 12, 2019):

In the case of drop-down we'll probably have to fork the semantic-ui drop-down code to add aria attributes and restructure the DOM into a more bootstrap like structure as it appears that aria doesn't like the submenu being contained by the "button" that opens the menu and can't see the values.

Regarding the only clickable items - I guess that means that anything that has an onclick needs to be activatable with focus?

@zeripath commented on GitHub (Oct 12, 2019): In the case of drop-down we'll probably have to fork the semantic-ui drop-down code to add aria attributes and restructure the DOM into a more bootstrap like structure as it appears that aria doesn't like the submenu being contained by the "button" that opens the menu and can't see the values. Regarding the only clickable items - I guess that means that anything that has an onclick needs to be activatable with focus?

GiteaMirror commented

https://github.com/zeripath/gitea/tree/aria-fixes

@zeripath commented on GitHub (Oct 12, 2019):

I've got a branch with a locally forked copy of drop-down here:

Which could be a starting point. The current changes mean that screen readers at least don't lose focus when a drop-down is activated but they can't see the menu items because of the above described issue.

@zeripath commented on GitHub (Oct 12, 2019): I've got a branch with a locally forked copy of drop-down here: https://github.com/zeripath/gitea/tree/aria-fixes Which could be a starting point. The current changes mean that screen readers at least don't lose focus when a drop-down is activated but they can't see the menu items because of the above described issue.

GiteaMirror commented

@Jookia commented on GitHub (Oct 12, 2019):

I'm working on fixing keyboard focus first since then the problems are just 'have focused element said by screen reader'

I've made some progress in my local branch, but I've found a nasty bug that while some drop down menus work with keyboard selection in Firefox 61, they just break in Firefox 68. But others don't. And Semantic UI upstream is dead, the community maintained fork is https://github.com/fomantic/Fomantic-UI/ maybe?

@Jookia commented on GitHub (Oct 12, 2019): I'm working on fixing keyboard focus first since then the problems are just 'have focused element said by screen reader' I've made some progress in my local branch, but I've found a nasty bug that while some drop down menus work with keyboard selection in Firefox 61, they just break in Firefox 68. But others don't. And Semantic UI upstream is dead, the community maintained fork is https://github.com/fomantic/Fomantic-UI/ maybe?

GiteaMirror commented

@zeripath commented on GitHub (Oct 12, 2019):

@Jookia I've been wondering about whether we should be switching to Fomantic - I think it's basically a dropin replacement. AFAICS fomantic doesn't fix the dropdown issue though.

@zeripath commented on GitHub (Oct 12, 2019): @Jookia I've been wondering about whether we should be switching to Fomantic - I think it's basically a dropin replacement. AFAICS fomantic doesn't fix the dropdown issue though.

GiteaMirror commented

@Jookia commented on GitHub (Oct 12, 2019):

Switching could be better than using Semantic which doesn't seem to have active development. It's a community led fork too, so it might have a better mind towards accessibility. In regard to where the fixes go, I think the HTML fixes like ARIA labels and tabindex belong in gitea's templates, and javascript focusing, clicking and keypress fixes go in Sementic/Fomantic.

@Jookia commented on GitHub (Oct 12, 2019): Switching could be better than using Semantic which doesn't seem to have active development. It's a community led fork too, so it might have a better mind towards accessibility. In regard to where the fixes go, I think the HTML fixes like ARIA labels and tabindex belong in gitea's templates, and javascript focusing, clicking and keypress fixes go in Sementic/Fomantic.

GiteaMirror commented

@dpy013 commented on GitHub (Oct 12, 2019):

I looked at the GitHub repository for Semantic-UI and Fomantic-UI.
Found that Fomantic-UI is more mundane than Semantic-UI update
Semantic-UI latest update is in 2018
Fomantic-UI latest update on September2019 2nd
Based on the above message, I support switching to Fomantic-UI because Fomantic-UI is highly active and can fix more bugs.
thanks

@dpy013 commented on GitHub (Oct 12, 2019): I looked at the GitHub repository for Semantic-UI and Fomantic-UI. Found that Fomantic-UI is more mundane than Semantic-UI update Semantic-UI latest update is in 2018 Fomantic-UI latest update on September2019 2nd Based on the above message, I support switching to Fomantic-UI because Fomantic-UI is highly active and can fix more bugs. thanks

GiteaMirror commented

@dpy013 commented on GitHub (Oct 12, 2019):

Another way is to have gitea clone Semantic-UI and maintain it yourself.

@dpy013 commented on GitHub (Oct 12, 2019): Another way is to have gitea clone Semantic-UI and maintain it yourself.

GiteaMirror commented

@zeripath commented on GitHub (Oct 12, 2019):

@dingpengyu that would be a bad idea. We have enough on our plate without managing a ui framework.

So Fomantic-UI isn't quite a perfect drop-in but I think it's mostly the same.

Edit: There are multiple places where we would need to fix the CSS and copy bits from the old CSS or account for changes. TBF I'm not certain if it's worth even persisting with fomantic/semantic and whether it would just be better to bite the bullet and migrate wholesale to another framework that actually works out the box. So I'm gonna abandon that branch and take a look at how easy it would be to migrate to bootstrap - simply because it just works.

@zeripath commented on GitHub (Oct 12, 2019): @dingpengyu that would be a bad idea. We have enough on our plate without managing a ui framework. So Fomantic-UI isn't quite a perfect drop-in but I think it's mostly the same. ---- Edit: There are multiple places where we would need to fix the CSS and copy bits from the old CSS or account for changes. TBF I'm not certain if it's worth even persisting with fomantic/semantic and whether it would just be better to bite the bullet and migrate wholesale to another framework that actually works out the box. So I'm gonna abandon that branch and take a look at how easy it would be to migrate to bootstrap - simply because it just works.

GiteaMirror commented

@Jookia commented on GitHub (Oct 12, 2019):

I did some more digging and found that browsers actually send click events to elements when you hit enter, so yay! But clicks aren't sent to parents, which I think is happening here. Maybe that's due to some 3D positioning due to CSS.

@Jookia commented on GitHub (Oct 12, 2019): I did some more digging and found that browsers actually send click events to elements when you hit enter, so yay! But clicks aren't sent to parents, which I think is happening here. Maybe that's due to some 3D positioning due to CSS.

GiteaMirror commented

@Jookia commented on GitHub (Oct 14, 2019):

Okay, so I've been spending a while digging through this to see what the problems are actually. So here's what I have for navigation.

tabindex is not set correctly on a lot of elements.

This means that the very basic accessibility feature of tabbing through items on a page is a bit wonky and doesn't work sometimes. I have this mostly fixed using some basic jQuery like this:

$("div.button:not([tabindex])").attr("tabindex", "0");
$("div.dropdown").find("a.item:not([tabindex])").attr("tabindex", "-1");
$("div.dropdown").find("i.dropdown.icon:not([tabindex])").attr("tabindex", "-1");

The first one being that some buttons don't have tabindexes, so you can't tab to them. (Deploy keys button for example)
The second being that items inside a dropdown menu should not have tabindexes, since they are supposed to be navigated by arrows. It also means that tabbing away from a dropdown menu will tab to an entry in it, which is then hidden because the dropdown menu is gone. Oops.
The third being that sometimes there's little arrows next to text for dropdown menus (the collaborator's page for example) that acts as a second dropdown menu source. So it's a waste of time to have to tab through the same dropdown menu twice.

More complex dropdown menus are kind of broken

If you go to the home page while logged in and try using the 'Switch dashboard context' menu (your username in top left under navigation) it won't let you tab down to 'New organization', this is because Sementic thinks this is some kind of submenu. So you can easily break the menu by hitting left and being unable to select anything so enter doesn't work. The easiest solution here is to just make it a linear menu.

Modal dialogs don't focus

I'm not sure how big a deal this will be to fix, but it means for example you can't remove a collaborator.

Confirming items in dropdown menus broken

I'm not too sure how exactly this is broken, but my current working theory is that all the events to use the dropdown menu are triggered when you click on the menu itself, not the actual items. I guess when you click the menu using a mouse you're actually clicking the menu element, not the item.

I think a possible fix here is to fire the menu click event when an item is selected.

Dropdown menu navigation without keys is broken

This one was a headache to figure out. So @xogium has Orca set to control Firefox's caret navigation. I'm not exactly sure what this does, but it controls Firefox's caret or cursor or item focus directly, which means this: You tab to the dropdown menu, the menu opens. You hit down, and Orca goes to the next element in HTML (the first menu item) and focuses it. Sementic then detects that you're no longer focusing the dropdown menu and closes it. Not helpful since you can't select anything.

I think the solution here would be making the dropdown menu JS more tolerant of external navigation methods instead of assuming that the dropdown menu is focused and that the only possible navigation is change of focus through mouse or arrow keys.

Screen reader output is rough

I'm assuming by the time the rest of those issues are fixed, dropdown menus will work with keyboard only and read out the focused item. So you will be able to navigate through the menus if you know what's on the page- you'll go to the collaborator settings and hear 'Jookia read delete' and based on me telling you that the middle is actually a dropdown menu for permissions, you can set the permissions. Ideally you should hear something like 'Jookia permissions dropdown delete'. There's a few different ways to do this, using ARIA labels for example. This applies site-wide and not just to dropdown menus.

Dropdown menus can include headings to tell you what's in the dropdown menu. These need to be read out too.

Other widgets

Dropdown menus can also act as search menus and narrow down results, this should be somehow read using a screen reader, including the status as to whether the search is done.

You can also add topics to your project! (The 'manage topics' text is inaccessible for reasons I don't understand yet) This is also a dropdown search menu that contains things you can delete. It's actually keyboard accessible already as a widget, but I haven't tested it with a screen reader.

@Jookia commented on GitHub (Oct 14, 2019): Okay, so I've been spending a while digging through this to see what the problems are actually. So here's what I have for navigation. 1. tabindex is not set correctly on a lot of elements. This means that the very basic accessibility feature of tabbing through items on a page is a bit wonky and doesn't work sometimes. I have this mostly fixed using some basic jQuery like this: ``` $("div.button:not([tabindex])").attr("tabindex", "0"); $("div.dropdown").find("a.item:not([tabindex])").attr("tabindex", "-1"); $("div.dropdown").find("i.dropdown.icon:not([tabindex])").attr("tabindex", "-1"); ``` The first one being that some buttons don't have tabindexes, so you can't tab to them. (Deploy keys button for example) The second being that items inside a dropdown menu should not have tabindexes, since they are supposed to be navigated by arrows. It also means that tabbing away from a dropdown menu will tab to an entry in it, which is then hidden because the dropdown menu is gone. Oops. The third being that sometimes there's little arrows next to text for dropdown menus (the collaborator's page for example) that acts as a second dropdown menu source. So it's a waste of time to have to tab through the same dropdown menu twice. 2. More complex dropdown menus are kind of broken If you go to the home page while logged in and try using the 'Switch dashboard context' menu (your username in top left under navigation) it won't let you tab down to 'New organization', this is because Sementic thinks this is some kind of submenu. So you can easily break the menu by hitting left and being unable to select anything so enter doesn't work. The easiest solution here is to just make it a linear menu. 3. Modal dialogs don't focus I'm not sure how big a deal this will be to fix, but it means for example you can't remove a collaborator. 4. Confirming items in dropdown menus broken I'm not too sure how exactly this is broken, but my current working theory is that all the events to use the dropdown menu are triggered when you click on the menu itself, not the actual items. I guess when you click the menu using a mouse you're actually clicking the menu element, not the item. I think a possible fix here is to fire the menu click event when an item is selected. 5. Dropdown menu navigation without keys is broken This one was a headache to figure out. So @xogium has Orca set to control Firefox's caret navigation. I'm not exactly sure what this does, but it controls Firefox's caret or cursor or item focus directly, which means this: You tab to the dropdown menu, the menu opens. You hit down, and Orca goes to the next element in HTML (the first menu item) and focuses it. Sementic then detects that you're no longer focusing the dropdown menu and closes it. Not helpful since you can't select anything. I think the solution here would be making the dropdown menu JS more tolerant of external navigation methods instead of assuming that the dropdown menu is focused and that the only possible navigation is change of focus through mouse or arrow keys. 6. Screen reader output is rough I'm assuming by the time the rest of those issues are fixed, dropdown menus will work with keyboard only and read out the focused item. So you will be able to navigate through the menus if you know what's on the page- you'll go to the collaborator settings and hear 'Jookia read delete' and based on me telling you that the middle is actually a dropdown menu for permissions, you can set the permissions. Ideally you should hear something like 'Jookia permissions dropdown delete'. There's a few different ways to do this, using ARIA labels for example. This applies site-wide and not just to dropdown menus. Dropdown menus can include headings to tell you what's in the dropdown menu. These need to be read out too. 7. Other widgets Dropdown menus can also act as search menus and narrow down results, this should be somehow read using a screen reader, including the status as to whether the search is done. You can also add topics to your project! (The 'manage topics' text is inaccessible for reasons I don't understand yet) This is also a dropdown search menu that contains things you can delete. It's actually keyboard accessible already as a widget, but I haven't tested it with a screen reader.

GiteaMirror commented

@xogium commented on GitHub (Oct 14, 2019):

Hi,
this is what the 'control caret navigation' checkbox of orca actually does:

This checkbox toggles Orca's caret navigation on and off. When it is on, Orca takes control of the caret as you arrow around within a page; when it is off, Gecko's native caret navigation is active.

Source: https://help.gnome.org/users/orca/stable/preferences_gecko.html.en

Hope this helps.

@xogium commented on GitHub (Oct 14, 2019): Hi, this is what the 'control caret navigation' checkbox of orca actually does: This checkbox toggles Orca's caret navigation on and off. When it is on, Orca takes control of the caret as you arrow around within a page; when it is off, Gecko's native caret navigation is active. Source: https://help.gnome.org/users/orca/stable/preferences_gecko.html.en Hope this helps.

GiteaMirror commented

@Jookia commented on GitHub (Oct 15, 2019):

Okay, so here's an update on the dropdown menu navigation situation.

Originally I thought the solution here was to let the user agent control focusing of dropdown menus, because this is how it worked with bootstrap and after spending a night hacking something together I got it working with Semetic's dropdown menus! So it look like I could fix the button pressing situation and I could ship something to xogium for real world use. However, I woke up the next day and did some more hacking. But I kept running in to weird bugs. So I looked at how bootstrap worked this out. Turns out: It didn't. In fact, I found only one dropdown menu on the web that works properly with Orca's caret navigation: https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html

The reason it works is because it takes cancels the caret navigation and manually handles the arrows in an intelligent way. It turns out this is the correct way to do things, at least according to ARIA: https://www.w3.org/TR/wai-aria-practices/#keyboard Specifically sections 6.5 and 6.6.

To summarize: The primary way to navigate a vanilla web page is using tab to switch between interactive components, keys to move within those components handled by Javascript, and other keys for navigating by the user agent, so things like page up/page down, Orca's up/down, etc.

So how does this work in practice with dropdowns? There's three main ways of writing a dropdown menu: Plain HTML, without key capturing, and with key capturing.

With plain HTML you use the <menu> element (oh, it's deprecated) or the <select> element which is hard to style, doesn't support rich content (so wouldn't work without big template changes) and without JS would require a form button that submits and has the server handle navigation. So you'd just not use it without JS in this case, but since you have JS you might as well make something that works better.

With key capturing, which is the way the w3 example works (and Sementic UI's works in theory, it's bugged at the moment) is to override user agent shortcuts and use those for navigation within the dropdown. So you tab to the dropdown menu, use arrows to navigate it, enter to confirm selection, or tab out. So this way you can tab past all the dropdown menus you want or navigate complex structures. The downside is it uses Javascript and overrides keys which seems gross and hacky.

Without key capturing, the dropdown menus are presented as elements you tab through as if it's a set of lists. It only requires a bit of JS to toggle the dropdown (or else why have the dropdown at all, the user would have to tab through every link). Seems cleaner, and nicer. This is the approach I wanted to work with: Having Semetic's dropdowns tolerant of focusing on the child elements so Orca could navigate them.

However after looking at a lot of dropdown boxes, it turns out not capturing keys is massively broken for screen readers that let you browse using caret mode. It works if you tab through dropdown menus, but if you use up/down it will break in a subtle fashion that isn't obvious to the user since they can still navigate through the dropdown menu, but they will skip past any content next to the dropdown box (such as other dropdown boxes in a row), or content under the dropdown menu.

I'll use a concrete example: A single dropdown button using bootstrap ( https://getbootstrap.com/docs/4.0/components/dropdowns/#single-button-dropdowns ) is tabbed to by the user, then opened. They then tab through the dropdown menu then past the dropdown menu to the 'copy to clipboard' link and then to the code snippet. This is the order of the HTML elements, so it works fine. However, if they use Orca's caret-based up/down they will still see all the contents of the dropdown menu, but skip the 'copy to clipboard' link. Yikes.

Things get messier with multiple dropdowns in a single row, which is Gitea's case: If you scroll a bit further down in that link you get to a bunch of dropdown menus you can tab through. Notice how you can tab properly between them in order, open them, tab through the contents, etc.

Now if you use Orca's caret navigation, it will skip any dropdown boxes you didn't explicitly tab to. You won't even know there are more than one unless you use tab. Now, the user is expected to tab between interactive elements so missing the boxes is going to be hard. The actual issue is that after opening one, moving past the last element will skip not only the 'copy to clipboard' link but any other dropdown boxes after the one you have open. So if you tab to the third dropdown box, scroll through it, you might not even know there's any after that. So you would have to tab back to see the last dropdown box, which is confusing as you passed it without knowing. It works the same in reverse: If you press up and accidentally move out of the dropdown menu, Orca will take you to the first dropdown box button. But pressing down will take you to the open dropdown menu. Worse, Orca might also just not read out the dropdown elements at all and instead focus you on the next dropdown menu, then skip over those and take you to the 'copy to clipboard' link.

This seems like a lot of weird buggy behavior, but I think the simple explanation is that Orca's up/down caret navigation takes you to the previous/next lines in the document instead of the HTML element order. Having a dropdown menu suddenly put new lines on top of your document causes problems. I haven't even tested this with other screen readers such as NVDA, or proprietary ones like JAWS that we can't even patch to work better.

So as far as I'm concerned, key capturing is the correct solution for dropdown menus. The current problem with Semantic's dropdown menus is it isn't capturing keys properly or telling the screen reader which element is selected, so that's what I'll try and fix.

@Jookia commented on GitHub (Oct 15, 2019): Okay, so here's an update on the dropdown menu navigation situation. Originally I thought the solution here was to let the user agent control focusing of dropdown menus, because this is how it worked with bootstrap and after spending a night hacking something together I got it working with Semetic's dropdown menus! So it look like I could fix the button pressing situation and I could ship something to xogium for real world use. However, I woke up the next day and did some more hacking. But I kept running in to weird bugs. So I looked at how bootstrap worked this out. Turns out: It didn't. In fact, I found only one dropdown menu on the web that works properly with Orca's caret navigation: https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html The reason it works is because it takes cancels the caret navigation and manually handles the arrows in an intelligent way. It turns out this is the correct way to do things, at least according to ARIA: https://www.w3.org/TR/wai-aria-practices/#keyboard Specifically sections 6.5 and 6.6. To summarize: The primary way to navigate a vanilla web page is using tab to switch between interactive components, keys to move within those components handled by Javascript, and other keys for navigating by the user agent, so things like page up/page down, Orca's up/down, etc. So how does this work in practice with dropdowns? There's three main ways of writing a dropdown menu: Plain HTML, without key capturing, and with key capturing. With plain HTML you use the ```<menu>``` element (oh, it's deprecated) or the ```<select>``` element which is hard to style, doesn't support rich content (so wouldn't work without big template changes) and without JS would require a form button that submits and has the server handle navigation. So you'd just not use it without JS in this case, but since you have JS you might as well make something that works better. With key capturing, which is the way the w3 example works (and Sementic UI's works in theory, it's bugged at the moment) is to override user agent shortcuts and use those for navigation within the dropdown. So you tab to the dropdown menu, use arrows to navigate it, enter to confirm selection, or tab out. So this way you can tab past all the dropdown menus you want or navigate complex structures. The downside is it uses Javascript and overrides keys which seems gross and hacky. Without key capturing, the dropdown menus are presented as elements you tab through as if it's a set of lists. It only requires a bit of JS to toggle the dropdown (or else why have the dropdown at all, the user would have to tab through every link). Seems cleaner, and nicer. This is the approach I wanted to work with: Having Semetic's dropdowns tolerant of focusing on the child elements so Orca could navigate them. However after looking at a lot of dropdown boxes, it turns out not capturing keys is massively broken for screen readers that let you browse using caret mode. It works if you tab through dropdown menus, but if you use up/down it will break in a subtle fashion that isn't obvious to the user since they can still navigate through the dropdown menu, but they will skip past any content next to the dropdown box (such as other dropdown boxes in a row), or content under the dropdown menu. I'll use a concrete example: A single dropdown button using bootstrap ( https://getbootstrap.com/docs/4.0/components/dropdowns/#single-button-dropdowns ) is tabbed to by the user, then opened. They then tab through the dropdown menu then past the dropdown menu to the 'copy to clipboard' link and then to the code snippet. This is the order of the HTML elements, so it works fine. However, if they use Orca's caret-based up/down they will still see all the contents of the dropdown menu, but skip the 'copy to clipboard' link. Yikes. Things get messier with multiple dropdowns in a single row, which is Gitea's case: If you scroll a bit further down in that link you get to a bunch of dropdown menus you can tab through. Notice how you can tab properly between them in order, open them, tab through the contents, etc. Now if you use Orca's caret navigation, it will skip any dropdown boxes you didn't explicitly tab to. You won't even know there are more than one unless you use tab. Now, the user is expected to tab between interactive elements so missing the boxes is going to be hard. The actual issue is that after opening one, moving past the last element will skip not only the 'copy to clipboard' link but any other dropdown boxes after the one you have open. So if you tab to the third dropdown box, scroll through it, you might not even know there's any after that. So you would have to tab back to see the last dropdown box, which is confusing as you passed it without knowing. It works the same in reverse: If you press up and accidentally move out of the dropdown menu, Orca will take you to the first dropdown box button. But pressing down will take you to the open dropdown menu. Worse, Orca might also just not read out the dropdown elements at all and instead focus you on the next dropdown menu, then skip over those and take you to the 'copy to clipboard' link. This seems like a lot of weird buggy behavior, but I think the simple explanation is that Orca's up/down caret navigation takes you to the previous/next lines in the document instead of the HTML element order. Having a dropdown menu suddenly put new lines on top of your document causes problems. I haven't even tested this with other screen readers such as NVDA, or proprietary ones like JAWS that we can't even patch to work better. So as far as I'm concerned, key capturing is the correct solution for dropdown menus. The current problem with Semantic's dropdown menus is it isn't capturing keys properly or telling the screen reader which element is selected, so that's what I'll try and fix.

GiteaMirror commented

@guillep2k commented on GitHub (Oct 16, 2019):

Thank you very much for this thorough analysis for this issue.

I must say I know nothing about assistive technologies (except that they exist), and I'm more than rusty in modern UI technologies, but it looks to me that the situation can be summarized as follows:

Key capturing seems hacky, requires Js but works, at least with Orca.
Orca has many features/bugs that makes it difficult to work with (oh, the irony!).

What is not clear to me is what side effects will experience the average user using a normal browser (with or without Js enabled) if we go for the key capturing solution. If there is any.

Because at the end of the day, if requiring Js will help more users than it will leave out, then I'd welcome that solution.

One thing that's maybe worth considering is: what if there is a custom theme specifically designed for this? For example, drop down menus could be translated into radio inputs, or given a different display attribute, etc. Or even all the way around: they could be radio inputs from the start and transformed into drop down menus for the default theme by means of CSS. I don't claim that these ideas are valid; I only want to point out that maybe there are other ways to look at this problem.

@guillep2k commented on GitHub (Oct 16, 2019): Thank you very much for this thorough analysis for this issue. I must say I know nothing about assistive technologies (except that they exist), and I'm more than rusty in modern UI technologies, but it looks to me that the situation can be summarized as follows: * Key capturing seems hacky, requires Js but works, at least with Orca. * Orca has many features/bugs that makes it difficult to work with (_oh, the irony!_). What is not clear to me is what side effects will experience the average user using a normal browser (with or without Js enabled) if we go for the _key capturing_ solution. If there is any. Because at the end of the day, if requiring Js will help more users than it will leave out, then I'd welcome that solution. One thing that's maybe worth considering is: what if there is a custom theme specifically designed for this? For example, drop down menus could be translated into radio inputs, or given a different `display` attribute, etc. Or even all the way around: they could be radio inputs from the start and transformed into drop down menus for the default theme by means of CSS. I don't claim that these ideas are valid; I only want to point out that maybe there are other ways to look at this problem.

GiteaMirror commented

@Jookia commented on GitHub (Oct 16, 2019):

I'm not sure if this is an Orca bug, but something certainly isn't right here. I would imagine what's happening under the hood is that Orca is moving the cursor to the next element that's also on the same line or lower. So a bit like tab but if it didn't go back upwards. But I'm not entirely sure how it works.

The good news is that Gitea already uses the key capturing for the dropdown menus. It's just broken. Gitea already requires JS to send POST requests without making a form or changing the page. Changing the server code to allow no-JS operation would be non-trivial. So since we require JS, it would make sense to just use JS to our advantage for this.

Of course, if we didn't want to do key capturing JS or make our own widget (already done by Semantic), we could use <select> element used for dropdown menus. It's not able to be styled well so it looks like a dropdown box which would look weird for navigation, but you could just have it be a 'Jump to' menu with lots of options the user could navigate with a separate 'Go' unless you want to use JS to submit the form when the item has been chosen.

@Jookia commented on GitHub (Oct 16, 2019): I'm not sure if this is an Orca bug, but something certainly isn't right here. I would imagine what's happening under the hood is that Orca is moving the cursor to the next element that's also on the same line or lower. So a bit like tab but if it didn't go back upwards. But I'm not entirely sure how it works. The good news is that Gitea already uses the key capturing for the dropdown menus. It's just broken. Gitea already requires JS to send POST requests without making a form or changing the page. Changing the server code to allow no-JS operation would be non-trivial. So since we require JS, it would make sense to just use JS to our advantage for this. Of course, if we didn't want to do key capturing JS or make our own widget (already done by Semantic), we could use ```<select>``` element used for dropdown menus. It's not able to be styled well so it looks like a dropdown box which would look weird for navigation, but you could just have it be a 'Jump to' menu with lots of options the user could navigate with a separate 'Go' unless you want to use JS to submit the form when the item has been chosen.

GiteaMirror commented

@Jookia commented on GitHub (Oct 17, 2019):

Ok so I was dead wrong about key capturing being bugged. Turns out Orca needs role=menuitem to agree to capture keys. Anyway, here's an initial PR for keyboard accessibility: https://github.com/go-gitea/gitea/pull/8555

Straight after I submit it I find that the accordian UI element isn't clicking properly. :)

@Jookia commented on GitHub (Oct 17, 2019): Ok so I was dead wrong about key capturing being bugged. Turns out Orca needs role=menuitem to agree to capture keys. Anyway, here's an initial PR for keyboard accessibility: https://github.com/go-gitea/gitea/pull/8555 Straight after I submit it I find that the accordian UI element isn't clicking properly. :)

GiteaMirror commented

@Jookia commented on GitHub (Oct 17, 2019):

So at the moment I have enough patches to do a release of my own WIP series: https://github.com/Jookia/gitea/releases/tag/v1.9.4-a11y1

As a summary of what's generally working:

Keyboard navigation
Dropdown menus screen reader support

Things still broken for keyboard users:

Accordion elements
Modal dialogs let you tab through background elements still

Things still broken for screen readers:

In general idk wtf I'm doing with aria roles
Search boxes
Dropdown menus sound really verbose
Tag fields
Modal dialogs don't speak
Labels to clarify what various dropdown menus do

Project stuff:

I should do a PR instead of clogging up this issue
I should have Sementic UI in a separate repo, but I haven't figured out how to build it yet

@Jookia commented on GitHub (Oct 17, 2019): So at the moment I have enough patches to do a release of my own WIP series: https://github.com/Jookia/gitea/releases/tag/v1.9.4-a11y1 As a summary of what's generally working: - Keyboard navigation - Dropdown menus screen reader support Things still broken for keyboard users: - Accordion elements - Modal dialogs let you tab through background elements still Things still broken for screen readers: - In general idk wtf I'm doing with aria roles - Search boxes - Dropdown menus sound really verbose - Tag fields - Modal dialogs don't speak - Labels to clarify what various dropdown menus do Project stuff: - I should do a PR instead of clogging up this issue - I should have Sementic UI in a separate repo, but I haven't figured out how to build it yet

GiteaMirror commented

@Flameborn commented on GitHub (Oct 20, 2019):

Thank you so much for your work on this.

Regarding accordions, while this is not standards by all means, I think for a start it is good enough if the elements are exposed to screen readers, which was a huge issue with dropdowns, for example there was no way to switch the UI language, choose a license, etc, because screen readers did not see the elements at all.

Looking forward to this becoming a part of Gitea, as it is currently a nightmare to use with a screen reader, even if it is the most lightweight and possibly the best Git solution.

@Flameborn commented on GitHub (Oct 20, 2019): Thank you so much for your work on this. Regarding accordions, while this is not standards by all means, I think for a start it is good enough if the elements are exposed to screen readers, which was a huge issue with dropdowns, for example there was no way to switch the UI language, choose a license, etc, because screen readers did not see the elements at all. Looking forward to this becoming a part of Gitea, as it is currently a nightmare to use with a screen reader, even if it is the most lightweight and possibly the best Git solution.

GiteaMirror commented

@Flameborn commented on GitHub (Jan 8, 2020):

I am currently running 1.11.0-rc1. The dropdown improvements really make a huge difference, Thanks to @Jookia's fixes in 1274ad864e.

This is not strictly UI-related, but it seems that SimpleMDE, Gitea's editor does not properly track cursor movement via a screen reader. As the project is unmaintained, the suggested version to switch to is Inscryb-MDE, which has a similar cursor tracking issue according to https://github.com/Inscryb/inscryb-markdown-editor/issues/18. Since this issue deals with accessibility, I'm posting this for future reference.

@Flameborn commented on GitHub (Jan 8, 2020): I am currently running 1.11.0-rc1. The dropdown improvements really make a huge difference, Thanks to @Jookia's fixes in https://github.com/go-gitea/gitea/commit/1274ad864e59b857344f3e11cc867d3146ddd64b. This is not strictly UI-related, but it seems that SimpleMDE, Gitea's editor does not properly track cursor movement via a screen reader. As the project is unmaintained, the suggested version to switch to is Inscryb-MDE, which has a similar cursor tracking issue according to https://github.com/Inscryb/inscryb-markdown-editor/issues/18. Since this issue deals with accessibility, I'm posting this for future reference.

GiteaMirror commented

@Jookia commented on GitHub (Jan 8, 2020):

I'm glad to hear that!

At the moment I'm a little stumped with this: I have to re-do my changes for FomanticUI and go through the mess that is the dropdown stuff again. I can do that, but the thing I really dread is going through all the templates and trying to figure out how to view each widget and test it later.

What would really, REALLY, REALLY help me do this if anyone's interested, is creating a list of inaccessible widgets in the HTML so I have some kind of goal or list of them to fix instead. So if anyone can do this it would help me zero in on what I need to do. Or even a list of all the pages on the website.

@Jookia commented on GitHub (Jan 8, 2020): I'm glad to hear that! At the moment I'm a little stumped with this: I have to re-do my changes for FomanticUI and go through the mess that is the dropdown stuff again. I can do that, but the thing I really dread is going through all the templates and trying to figure out how to view each widget and test it later. What would really, REALLY, REALLY help me do this if anyone's interested, is creating a list of inaccessible widgets in the HTML so I have some kind of goal or list of them to fix instead. So if anyone can do this it would help me zero in on what I need to do. Or even a list of all the pages on the website.

GiteaMirror commented

@Flameborn commented on GitHub (Jan 8, 2020):

According to the rc1 change log, Gitea is already using Fomantic UI.

I assume there is no universal way to fix the widgets, i.e. do you have to go through each page and add tags manually, rather than change how widgets are created/focused? This is without me looking at the source, so please excuse my ignorance. If it helps, I can go through the template pages and give you a list of widgets. I think they are mostly dropdowns or accordions, though I think accordion items are focusable, at least via tab and screen reader commands.

The hard part is to figure out what elements on a page are invisible to a screen reader, as with dropdowns, I had to disable styles and navigate the incredibly cluttered page without your fix, so often I was not aware that there were more options.

I think testing should not be a problem, as many people would be happy to do it for you, as far as screen reader/keyboard accessibility without visuals is concerned.

On 2020. Jan 8., at 8:01, Jookia notifications@github.com wrote:

I'm glad to hear that!

At the moment I'm a little stumped with this: I have to re-do my changes for FomanticUI and go through the mess that is the dropdown stuff again. I can do that, but the thing I really dread is going through all the templates and trying to figure out how to view each widget and test it later.

What would really, REALLY, REALLY help me do this if anyone's interested, is creating a list of inaccessible widgets in the HTML so I have some kind of goal or list of them to fix instead. So if anyone can do this it would help me zero in on what I need to do. Or even a list of all the pages on the website.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/7057?email_source=notifications&email_token=AAHLD4GFQNVGXO6CYUOMCCLQ4V237A5CNFSM4HPYFNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEILMOGY#issuecomment-571918107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4AW3NYNGRMDQ25LEC3Q4V237ANCNFSM4HPYFNCQ.

@Flameborn commented on GitHub (Jan 8, 2020): According to the rc1 change log, Gitea is already using Fomantic UI. I assume there is no universal way to fix the widgets, i.e. do you have to go through each page and add tags manually, rather than change how widgets are created/focused? This is without me looking at the source, so please excuse my ignorance. If it helps, I can go through the template pages and give you a list of widgets. I think they are mostly dropdowns or accordions, though I think accordion items are focusable, at least via _tab_ and screen reader commands. The hard part is to figure out what elements on a page are invisible to a screen reader, as with dropdowns, I had to disable styles and navigate the incredibly cluttered page without your fix, so often I was not aware that there were more options. I think testing should not be a problem, as many people would be happy to do it for you, as far as screen reader/keyboard accessibility without visuals is concerned. > On 2020. Jan 8., at 8:01, Jookia <notifications@github.com> wrote: > > I'm glad to hear that! > > At the moment I'm a little stumped with this: I have to re-do my changes for FomanticUI and go through the mess that is the dropdown stuff again. I can do that, but the thing I really dread is going through all the templates and trying to figure out how to view each widget and test it later. > > What would really, REALLY, REALLY help me do this if anyone's interested, is creating a list of inaccessible widgets in the HTML so I have some kind of goal or list of them to fix instead. So if anyone can do this it would help me zero in on what I need to do. Or even a list of all the pages on the website. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/7057?email_source=notifications&email_token=AAHLD4GFQNVGXO6CYUOMCCLQ4V237A5CNFSM4HPYFNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEILMOGY#issuecomment-571918107>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4AW3NYNGRMDQ25LEC3Q4V237ANCNFSM4HPYFNCQ>. >

GiteaMirror commented

@Jookia commented on GitHub (Jan 8, 2020):

Yeah, there's no universal way from what I can see. There's a lot of different techniques that need to be applied, and some HTML needs to be cleaned up. There's wrong tabindexes, buttons that exploit nested mouse events, and non-ARIA Javascript. The code I wrote tries to figure out the appropriate aria role based on the HTML, which works fine for now. There's also the fact that some widgets require squinting hard at the ARIA spec to figure out what they should be classed as.

I'm not sure how much of the HTML should be fixed with Javascript at runtime, if any. Currently tabindexes are set by Javascript for dropdowns at runtime.

Edit: This would be a lot easier if I knew what I was doing, as you can imagine ;)

@Jookia commented on GitHub (Jan 8, 2020): Yeah, there's no universal way from what I can see. There's a lot of different techniques that need to be applied, and some HTML needs to be cleaned up. There's wrong tabindexes, buttons that exploit nested mouse events, and non-ARIA Javascript. The code I wrote tries to figure out the appropriate aria role based on the HTML, which works fine for now. There's also the fact that some widgets require squinting hard at the ARIA spec to figure out what they should be classed as. I'm not sure how much of the HTML should be fixed with Javascript at runtime, if any. Currently tabindexes are set by Javascript for dropdowns at runtime. Edit: This would be a lot easier if I knew what I was doing, as you can imagine ;)

GiteaMirror commented

@Jookia commented on GitHub (Jan 12, 2020):

So, dropping the bombshell here: The only proper way to make Gitea properly accessible in its current form is a UI rewrite with accessibility in mind. This ties in with #5937 . At the moment my plan is to fork Gitea then slowly make that version accessible in my free time. All the hacking I'm doing will maybe in a year or two I'll get the code base and its dependencies barely accessible in my free time. This is just paying off technical debt. I will not be upstreaming this work.

The developers of Gitea need to start over with the UI and implement a policy that things only get merged if they're accessible and up to WCAG standards and usable with screen readers and other input devices.

@Jookia commented on GitHub (Jan 12, 2020): So, dropping the bombshell here: The only proper way to make Gitea properly accessible in its current form is a UI rewrite with accessibility in mind. This ties in with #5937 . At the moment my plan is to **fork Gitea** then slowly make that version accessible in my free time. All the hacking I'm doing will maybe in a year or two I'll get the code base and its dependencies barely accessible in my free time. This is just paying off technical debt. **I will not be upstreaming this work.** The developers of Gitea need to start over with the UI and implement a policy that things only get merged if they're accessible and up to WCAG standards and usable with screen readers and other input devices.

GiteaMirror commented

@zeripath commented on GitHub (Jan 13, 2020):

@Jookia I don't know what has spurred you to this decision but I think it's the wrong choice.

We're an open source community there is no need to work in the dark.

Rewriting the whole UI by yourself sounds like a miserable and interminable task - especially if you don't intend to upstream as we will forever be stomping over your work, and we'll never learn what it is we have to do to make things work.

Let's start small. Focus on one screen or one thing.

Avoid making big PRs except where necessary.

We need to learn the patterns that make things accessible.

I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help.

Yes some results may end up suboptimal - but if you can tell us why they're suboptimal we can approach upstream or just fix it ourselves. If there's something that needs completely rewriting - for example the diff generation - you can help us rewrite.

Some of the problems we literally do not know are there or have zero idea as to what we're supposed to do.

@zeripath commented on GitHub (Jan 13, 2020): @Jookia I don't know what has spurred you to this decision but I think it's the wrong choice. We're an open source community there is no need to work in the dark. Rewriting the whole UI by yourself sounds like a miserable and interminable task - especially if you don't intend to upstream as we will forever be stomping over your work, and we'll never learn what it is we have to do to make things work. Let's start small. Focus on one screen or one thing. Avoid making big PRs except where necessary. We need to learn the patterns that make things accessible. I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help. Yes some results may end up suboptimal - but if you can tell us why they're suboptimal we can approach upstream or just fix it ourselves. If there's something that needs completely rewriting - for example the diff generation - you can help us rewrite. Some of the problems we literally do not know are there or have zero idea as to what we're supposed to do.

GiteaMirror commented

@Jookia commented on GitHub (Jan 13, 2020):

On Sun, Jan 12, 2020 at 10:15:35PM -0800, zeripath wrote:

@Jookia I don't know what has spurred you to this decision but I think it's the wrong choice.

We're an open source community there is no need to work in the dark.

It's a lot easier on my own energy levels especially since I'm doing
this alone anyway.

Rewriting the whole UI by yourself sounds like a miserable and interminable task - especially if you don't intend to upstream as we will forever be stomping over your work, and we'll never learn what it is we have to do to make things work.

I'm not rewriting the UI, I'm just fixing up the existing UI.
The entire UI needs to be rewritten for proper accessibility, so that's
up to someone else to do.

Let's start small. Focus on one screen or one thing.

I'm doing that in my fork.

Avoid making big PRs except where necessary.

I'm fairly sure I did that I think.

But with the amount of changes needed to even make Gitea barely
accessible, I'm not comfortable with upstreaming them simply because of
the inevitable pushback from changing the UI. Even small things like
changing the red asterisks on the install screen to text that says
'required' would cause massive issues in getting merged in to Fomantic,
and can't be vendored due to Gitea's insistence on using upstream code.

We need to learn the patterns that make things accessible.

I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help.

I'm not disappearing, I'm happy to answer questions and provide links to
resources for people to learn. I have no time to deal with upstreaming
changes.

Yes some results may end up suboptimal - but if you can tell us why they're suboptimal we can approach upstream or just fix it ourselves. If there's something that needs completely rewriting - for example the diff generation - you can help us rewrite.

Most of the UI needs rewriting.

Some of the problems we literally do not know are there or have zero idea as to what we're supposed to do.

Yeah that sucks, but the only solution for this is for you and other
maintainers to learn this stuff. Having a single person act as the
accessibility developer is not going to work.

@Jookia commented on GitHub (Jan 13, 2020): On Sun, Jan 12, 2020 at 10:15:35PM -0800, zeripath wrote: > @Jookia I don't know what has spurred you to this decision but I think it's the wrong choice. > > We're an open source community there is no need to work in the dark. It's a lot easier on my own energy levels especially since I'm doing this alone anyway. > Rewriting the whole UI by yourself sounds like a miserable and interminable task - especially if you don't intend to upstream as we will forever be stomping over your work, and we'll never learn what it is we have to do to make things work. I'm not rewriting the UI, I'm just fixing up the existing UI. The entire UI needs to be rewritten for proper accessibility, so that's up to someone else to do. > Let's start small. Focus on one screen or one thing. I'm doing that in my fork. > Avoid making big PRs except where necessary. I'm fairly sure I did that I think. But with the amount of changes needed to even make Gitea barely accessible, I'm not comfortable with upstreaming them simply because of the inevitable pushback from changing the UI. Even small things like changing the red asterisks on the install screen to text that says 'required' would cause massive issues in getting merged in to Fomantic, and can't be vendored due to Gitea's insistence on using upstream code. > We need to learn the patterns that make things accessible. > > I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help. I'm not disappearing, I'm happy to answer questions and provide links to resources for people to learn. I have no time to deal with upstreaming changes. > Yes some results may end up suboptimal - but if you can tell us why they're suboptimal we can approach upstream or just fix it ourselves. If there's something that needs completely rewriting - for example the diff generation - you can help us rewrite. Most of the UI needs rewriting. > Some of the problems we literally do not know are there or have zero idea as to what we're supposed to do. Yeah that sucks, but the only solution for this is for you and other maintainers to learn this stuff. Having a single person act as the accessibility developer is not going to work.

GiteaMirror commented

@zeripath commented on GitHub (Jan 13, 2020):

But yet by privately forking Gitea you're doing precisely that.

@zeripath commented on GitHub (Jan 13, 2020): But yet by privately forking Gitea you're doing precisely that.

GiteaMirror commented

@zeripath commented on GitHub (Jan 13, 2020):

Let's look at the "required" issue.

Fomantic's example looks like:

<div class="ui form">
  <div class="required field">
    <label>Last name</label>
    <input type="text" placeholder="Full Name">
  </div>
  <div class="required inline field">
    <div class="ui checkbox">
      <input type="checkbox" tabindex="0" class="hidden">
      <label>I agree to the terms and conditions</label>
    </div>
  </div>
</div>

I guess that's not correct for ARIA.

I guess we just need to stick the required attribute back on the inputs?
The label also needs a for?

There's no need for upstream changes here - although an issue should be opened at fomantic to say they are recommending something that cannot work with screen readers.

A simple PR that just does the template changes of ensuring that required attributes are set and explains why this is necessary should not get any "pushback" at all. It would then be clear how templates have to be written to do this and we all learn.

How were you intending on fixing this? Was it with some JavaScript that would walk the DOM and fix it up? That would not only get pushback but would not disseminate the knowledge of how to write the templates correctly.

@zeripath commented on GitHub (Jan 13, 2020): Let's look at the "required" issue. Fomantic's example looks like: ```html <div class="ui form"> <div class="required field"> <label>Last name</label> <input type="text" placeholder="Full Name"> </div> <div class="required inline field"> <div class="ui checkbox"> <input type="checkbox" tabindex="0" class="hidden"> <label>I agree to the terms and conditions</label> </div> </div> </div> ``` I guess that's not correct for ARIA. * I guess we just need to stick the required attribute back on the inputs? * The label also needs a for? There's no need for upstream changes here - although an issue should be opened at fomantic to say they are recommending something that cannot work with screen readers. A simple PR that just does the template changes of ensuring that required attributes are set and explains why this is necessary should not get any "pushback" at all. It would then be clear how templates have to be written to do this and we all learn. How were you intending on fixing this? Was it with some JavaScript that would walk the DOM and fix it up? That would not only get pushback but would not disseminate the knowledge of how to write the templates correctly.

GiteaMirror commented

@Jookia commented on GitHub (Jan 13, 2020):

I'm not intending to fix it aside from changing the CSS so the asterisk goes from a star to the text 'required'.

@Jookia commented on GitHub (Jan 13, 2020): I'm not intending to fix it aside from changing the CSS so the asterisk goes from a star to the text 'required'.

GiteaMirror commented

@Jookia commented on GitHub (Jan 13, 2020):

But yet by privately forking Gitea you're doing precisely that.

Yeah I guess that's true (even though my fork will be public). After trying and failing to make accordions accessible in Fomantic UI, and having it randomly break in a weird way because I changed the HTML I think I'm just done with all of this.

@Jookia commented on GitHub (Jan 13, 2020): > But yet by privately forking Gitea you're doing precisely that. Yeah I guess that's true (even though my fork will be public). After trying and failing to make accordions accessible in Fomantic UI, and having it randomly break in a weird way because I changed the HTML I think I'm just done with all of this.

GiteaMirror commented

@dpy013 commented on GitHub (Feb 10, 2020):

But yet by privately forking Gitea you're doing precisely that.

Yeah I guess that's true (even though my fork will be public). After trying and failing to make accordions accessible in Fomantic UI, and having it randomly break in a weird way because I changed the HTML I think I'm just done with all of this.
hello all
Thank you all for your work
may I ask
What are the accessibility issues with current gitea?
thanks

@dpy013 commented on GitHub (Feb 10, 2020): > > But yet by privately forking Gitea you're doing precisely that. > > Yeah I guess that's true (even though my fork will be public). After trying and failing to make accordions accessible in Fomantic UI, and having it randomly break in a weird way because I changed the HTML I think I'm just done with all of this. hello all Thank you all for your work may I ask What are the accessibility issues with current gitea? thanks

GiteaMirror commented

@Flameborn commented on GitHub (Feb 10, 2020):

Multiple things, unfortunately.

The UI toolkit has inaccessible controls, for example the accordions, the dropdowns, there are a horde of images visible to screen readers on the dashboard as part of the calendar, etc.
Keyboard access is also broken in many places. These have been partially fixed, however, they are very easy to break again, as they are not part of the UI toolkit, mainly because Gitea is sticking to upstream versions to my knowledge at the moment.

In addition, the editor currently used for the Wiki pages is inaccessible, as there is absolutely no cursor feedback when navigating via a screen reader. I have raised an issue about this on their GitHub page, but unfortunately nothing is happening with it at the moment.

On 2020. Feb 10., at 12:34, eric notifications@github.com wrote:

But yet by privately forking Gitea you're doing precisely that.

Yeah I guess that's true (even though my fork will be public). After trying and failing to make accordions accessible in Fomantic UI, and having it randomly break in a weird way because I changed the HTML I think I'm just done with all of this.
hello all
Thank you all for your work
may I ask
What are the accessibility issues with current gitea?
thanks

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/7057?email_source=notifications&email_token=AAHLD4BVVRSNMZLG5AY7XN3RCE3TDA5CNFSM4HPYFNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELIF24Q#issuecomment-584080754, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4EXBWSUMDKEFDWNRL3RCE3TDANCNFSM4HPYFNCQ.

@Flameborn commented on GitHub (Feb 10, 2020): Multiple things, unfortunately. The UI toolkit has inaccessible controls, for example the accordions, the dropdowns, there are a horde of images visible to screen readers on the dashboard as part of the calendar, etc. Keyboard access is also broken in many places. These have been partially fixed, however, they are very easy to break again, as they are not part of the UI toolkit, mainly because Gitea is sticking to upstream versions to my knowledge at the moment. In addition, the editor currently used for the Wiki pages is inaccessible, as there is absolutely no cursor feedback when navigating via a screen reader. I have raised an issue about this on their GitHub page, but unfortunately nothing is happening with it at the moment. > On 2020. Feb 10., at 12:34, eric <notifications@github.com> wrote: > > But yet by privately forking Gitea you're doing precisely that. > > Yeah I guess that's true (even though my fork will be public). After trying and failing to make accordions accessible in Fomantic UI, and having it randomly break in a weird way because I changed the HTML I think I'm just done with all of this. > hello all > Thank you all for your work > may I ask > What are the accessibility issues with current gitea? > thanks > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/7057?email_source=notifications&email_token=AAHLD4BVVRSNMZLG5AY7XN3RCE3TDA5CNFSM4HPYFNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELIF24Q#issuecomment-584080754>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4EXBWSUMDKEFDWNRL3RCE3TDANCNFSM4HPYFNCQ>. >

GiteaMirror commented

@ogomez92 commented on GitHub (Mar 7, 2020):

Wow what a bunch of issues, I'll be surprised if this ever gets fixed. time to switch to Gitlab entirely I think What a shame, as this project is really nice.!

@ogomez92 commented on GitHub (Mar 7, 2020): Wow what a bunch of issues, I'll be surprised if this ever gets fixed. time to switch to Gitlab entirely I think What a shame, as this project is really nice.!

GiteaMirror commented

@lafriks commented on GitHub (Mar 7, 2020):

@ogomez92 feel free to help us on this as this project is completely community based and there is no company behind it to pay the bills

@lafriks commented on GitHub (Mar 7, 2020): @ogomez92 feel free to help us on this as this project is completely community based and there is no company behind it to pay the bills

GiteaMirror commented

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

I'd love to, but if the main developers aren't looking at this thread
and they are willing to change to a different UI, it does not look
very hopeful.

On 3/7/20, Lauris BH notifications@github.com wrote:

@ogomez92 feel free to help us on this as this project is completely
community based and there is no company behind it to pay the bills

--
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/7057#issuecomment-596139077

@ogomez92 commented on GitHub (Mar 8, 2020): I'd love to, but if the main developers aren't looking at this thread and they are willing to change to a different UI, it does not look very hopeful. On 3/7/20, Lauris BH <notifications@github.com> wrote: > @ogomez92 feel free to help us on this as this project is completely > community based and there is no company behind it to pay the bills > > -- > 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/7057#issuecomment-596139077

GiteaMirror commented

Discussion of Gitea roadmap

@dpy013 commented on GitHub (May 11, 2020):

@dpy013 commented on GitHub (May 11, 2020): [Discussion of Gitea roadmap](https://github.com/go-gitea/gitea/issues/6998)

GiteaMirror commented

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

Could you clarify why you linked that, @dingpengyu ? It doesn't mention accesibility and at this point it's locked.

@Jookia commented on GitHub (May 11, 2020): Could you clarify why you linked that, @dingpengyu ? It doesn't mention accesibility and at this point it's locked.

GiteaMirror commented

2025-11-02 05:11:03 -06:00

@dpy013 commented on GitHub (May 17, 2020):

Discussion of Gitea roadmap
The reason I quote this issue is that I hope that in future development, gitea can fully consider accessibility.
thanks

@dpy013 commented on GitHub (May 17, 2020): > [Discussion of Gitea roadmap](https://github.com/go-gitea/gitea/issues/6998) The reason I quote this issue is that I hope that in future development, gitea can fully consider accessibility. thanks

GiteaMirror commented

@Flameborn commented on GitHub (Jul 16, 2021):

As it stands, the merge of https://github.com/go-gitea/gitea/pull/15951 and https://github.com/go-gitea/gitea/pull/15193 currently break the very minimal screen reader support. Please do not upgrade to https://github.com/go-gitea/gitea/tree/v1.15.0-rc1 (or above) if you use screen reading software.

Knowing that Gitea is used and relied on by keyboard/screen reader users, yet still merging accessibility-breaking changes is a very unwise move, especially because, to my knowledge, there is nothing else that provides the same (or even a similar) feature set as Gitea. I understand that backward compatibility requires a lot of effort to maintain, but without it, you are essentially ignoring users (by choice) who have to rely on screen reading software, which is not by choice, by the way. Please strongly reconsider this, especially @silverwind and @techknowlogick. We don't just lose some #a11y, we lose most of what's been there. In fact, there have been no other accessibility improvements made other than these two, as far as I know.

Many modern UI toolkits have ARIA-enabled controls these days, or due to their design, they require very minimal ARIA/javascript to make their controls keyboard/screen reader accessible.

I still believe that since there is no interest whatsoever in accessibility upstream, dropping Fomantic and switching to something like Bootstrap, React, etc, is the way forward in ensuring that Gitea can be accessed equally. Until this is done, however, blind/visually impaired users are currently left in the dark (no pun intended).

@Flameborn commented on GitHub (Jul 16, 2021): As it stands, the merge of https://github.com/go-gitea/gitea/pull/15951 and https://github.com/go-gitea/gitea/pull/15193 currently break the very minimal screen reader support. Please do not upgrade to https://github.com/go-gitea/gitea/tree/v1.15.0-rc1 (or above) if you use screen reading software. Knowing that Gitea is used and relied on by keyboard/screen reader users, yet still merging accessibility-breaking changes is a very unwise move, especially because, to my knowledge, there is nothing else that provides the same (or even a similar) feature set as Gitea. I understand that backward compatibility requires a lot of effort to maintain, but without it, you are essentially ignoring users (by choice) who have to rely on screen reading software, which is not by choice, by the way. Please strongly reconsider this, especially @silverwind and @techknowlogick. We don't just lose *some* #a11y, we lose *most* of what's been there. In fact, there have been no other accessibility improvements made other than these two, as far as I know. Many modern UI toolkits have ARIA-enabled controls these days, or due to their design, they require very minimal ARIA/javascript to make their controls keyboard/screen reader accessible. I still believe that since there is no interest whatsoever in accessibility upstream, dropping Fomantic and switching to something like Bootstrap, React, etc, is the way forward in ensuring that Gitea can be accessed equally. Until this is done, however, blind/visually impaired users are currently left in the dark (no pun intended).

GiteaMirror commented

2025-11-02 05:11:03 -06:00

@silverwind commented on GitHub (Jul 16, 2021):

Yes we know Fomantic sucks and it needs to be replaced but it's not going to be a simple effort because of how deeply we are integrated with it.

If someone could just post how the HTML of a fomantic dropdown has to look to be accessible (e.g. where to add aria attributes), I guess we could hack up a bandaid fix for it using MutationObserver or similar. I don't have a screenreader or the motivation to test with one, just give me the expected HTML please.

@silverwind commented on GitHub (Jul 16, 2021): Yes we know Fomantic sucks and it needs to be replaced but it's not going to be a simple effort because of how deeply we are integrated with it. If someone could just post how the HTML of a fomantic dropdown has to look to be accessible (e.g. where to add `aria` attributes), I guess we could hack up a bandaid fix for it using `MutationObserver` or similar. I don't have a screenreader or the motivation to test with one, just give me the expected HTML please.

GiteaMirror commented

2025-11-02 05:11:03 -06:00

@Jookia commented on GitHub (Jul 16, 2021):

There's no expected HTML for this because Fomantic doesn't support it.

For anyone interested, GitBucket is usable and okay at accessibility.

@Jookia commented on GitHub (Jul 16, 2021): There's no expected HTML for this because Fomantic doesn't support it. For anyone interested, GitBucket is usable and okay at accessibility.

GiteaMirror commented

@Jookia commented on GitHub (Jul 16, 2021):

Sorry for the double post but I want to throw my two cents in here: Fomantic's UI isn't inaccessible. Fomantic provides mechanisms for creating widgets. I spent like a sleep deprived week and managed to get most drop downs working. This is an issue of Gitea developers not devoting time to doing the same work and making their GUI accessible. If Gitea switched to bootstrap tomorrow and didn't bother to test their UI with a screen reader, it would absolutely break in the same way.

@Jookia commented on GitHub (Jul 16, 2021): Sorry for the double post but I want to throw my two cents in here: Fomantic's UI isn't inaccessible. Fomantic provides mechanisms for creating widgets. I spent like a sleep deprived week and managed to get most drop downs working. This is an issue of Gitea developers not devoting time to doing the same work and making their GUI accessible. If Gitea switched to bootstrap tomorrow and didn't bother to test their UI with a screen reader, it would absolutely break in the same way.

GiteaMirror commented

@Flameborn commented on GitHub (Jul 16, 2021):

Yes we know Fomantic sucks and it needs to be replaced but it's not going to be a simple effort because of how deeply we are integrated with it.

I wasn't implying that it would be a simple effort, merely that removing some #a11y improvements, even if they are hacky at the moment until a better solution is ready is quite frankly an ignorant choice. There are people who rely on screen readers for one reason or another, neither of which is a choice, unfortunately. I'm definitely aware that rewriting the UI is going to take some effort, but this should not be used as an excuse. The existing solution, as stated before, will work until the rewrite happens. It is not perfect, but it at least makes Gitea usable. Without it, none of the currently available screen readers will work with the software, as expected.

If someone could just post how the HTML of a fomantic dropdown has to look to be accessible (e.g. where to add aria attributes), I guess we could hack up a bandaid fix for it using MutationObserver or similar. I don't have a screenreader or the motivation to test with one, just give me the expected HTML please.
This is also a solution, however it should have been the obvious choice before removing anything. I think neither of the screen reader users, me included, are familiar with Fomantic, so unfortunately we will not be able to provide adequate help for this, other than testing, however, I believe there are ample ARIA examples, for example https://www.webaxe.org/accessible-custom-select-dropdowns/

I think a good start would be to have a menuitem role for dropdown and accordion items, which are included in the parent having a menubar role. Then, keyboard access is to do with tracking which item has focus and making sure it changes to the next/previous items, as well as making sure that the focus cannot get out of the menu while it's open. Enter or space usually activates a menu item, it might be required to trap these as well. I'm guessing this is what largely @Jookia ended up doing as well, but of course the complexity of Fomantic can make this a bit more challenging, which is why it probably took a week to implement this.

Linux uses gnome-orca, for Windows, you can get NVDA from https://nvda-project.org, MacOS and iOS has VoiceOver built-in (cmd+f5, or settings/general/accessibility).

@Flameborn commented on GitHub (Jul 16, 2021): > Yes we know Fomantic sucks and it needs to be replaced but it's not going to be a simple effort because of how deeply we are integrated with it. I wasn't implying that it would be a simple effort, merely that removing some #a11y improvements, even if they are hacky at the moment until a better solution is ready is quite frankly an ignorant choice. There are people who rely on screen readers for one reason or another, neither of which is a choice, unfortunately. I'm definitely aware that rewriting the UI is going to take some effort, but this should not be used as an excuse. The existing solution, as stated before, will work until the rewrite happens. It is not perfect, but it at least makes Gitea usable. Without it, none of the currently available screen readers will work with the software, as expected. > If someone could just post how the HTML of a fomantic dropdown has to look to be accessible (e.g. where to add `aria` attributes), I guess we could hack up a bandaid fix for it using `MutationObserver` or similar. I don't have a screenreader or the motivation to test with one, just give me the expected HTML please. This is also a solution, however it should have been the obvious choice before removing anything. I think neither of the screen reader users, me included, are familiar with Fomantic, so unfortunately we will not be able to provide adequate help for this, other than testing, however, I believe there are ample ARIA examples, for example https://www.webaxe.org/accessible-custom-select-dropdowns/ I think a good start would be to have a *menuitem* role for dropdown and accordion items, which are included in the parent having a *menubar* role. Then, keyboard access is to do with tracking which item has focus and making sure it changes to the next/previous items, as well as making sure that the focus cannot get out of the menu while it's open. Enter or space usually activates a menu item, it might be required to trap these as well. I'm guessing this is what largely @Jookia ended up doing as well, but of course the complexity of Fomantic can make this a bit more challenging, which is why it probably took a week to implement this. Linux uses gnome-orca, for Windows, you can get NVDA from https://nvda-project.org, MacOS and iOS has VoiceOver built-in (cmd+f5, or settings/general/accessibility).

GiteaMirror commented

@fnetX commented on GitHub (Jul 17, 2021):

Hey @Flameborn and everyone else, looking into this as someone not really familiar with frontend stuff and Gitea development, but interested in getting this improved. Are you available to open a new issue that can describe precisely what breaks with these PRs, linking them and maybe referring this issue?

I know, when there are many problems, it's not always easy to file single precise issues, but they help a lot in fixing problems, and it's easier to send them to external people, maybe hire someone to get this done. I'd really appreciate your input here, because I only understand that Gitea has a general accessibility issue and that these PRs broke something in addition, but I don't really understand yet what needs an urgent fix before releasing (or deploying) Gitea 1.15.

Thank you.

@fnetX commented on GitHub (Jul 17, 2021): Hey @Flameborn and everyone else, looking into this as someone not really familiar with frontend stuff and Gitea development, but interested in getting this improved. Are you available to open a new issue that can describe precisely what breaks with these PRs, linking them and maybe referring this issue? I know, when there are many problems, it's not always easy to file single precise issues, but they help a lot in fixing problems, and it's easier to send them to external people, maybe hire someone to get this done. I'd really appreciate your input here, because I only understand that Gitea has a general accessibility issue and that these PRs broke something in addition, but I don't really understand yet what needs an urgent fix before releasing (or deploying) Gitea 1.15. Thank you.

GiteaMirror commented

@Jookia commented on GitHub (Jul 17, 2021):

It breaks screen reader support for accordion widgets and dropdown widgets.

Download a screen reader and try comparing Gitea versions.

I don't mean to sound salty, but what's the point of opening issues if
there's no interest in taking accessibility regressions seriously upstream?

On Fri, Jul 16, 2021 at 05:19:13PM -0700, fnetX (aka fralix) wrote:

Hey @Flameborn and everyone else, looking into this as someone not really familiar with frontend stuff and Gitea development, but interested in getting this improved. Are you available to open a new issue that can describe precisely what breaks with these PRs, linking them and maybe referring this issue?

I know, when there are many problems, it's not always easy to file single precise issues, but they help a lot in fixing problems, and it's easier to send them to external people, maybe hire someone to get this done. I'd really appreciate your input here, because I only understand that Gitea has a general issue and that these PRs broke something in addition, but I don't really get what needs an urgent fix before releasing (or deploying) Gitea 1.15.

Thank you.

--
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/7057#issuecomment-881781999

@Jookia commented on GitHub (Jul 17, 2021): It breaks screen reader support for accordion widgets and dropdown widgets. Download a screen reader and try comparing Gitea versions. I don't mean to sound salty, but what's the point of opening issues if there's no interest in taking accessibility regressions seriously upstream? On Fri, Jul 16, 2021 at 05:19:13PM -0700, fnetX (aka fralix) wrote: > Hey @Flameborn and everyone else, looking into this as someone not really familiar with frontend stuff and Gitea development, but interested in getting this improved. Are you available to open a new issue that can describe precisely what breaks with these PRs, linking them and maybe referring this issue? > > I know, when there are many problems, it's not always easy to file single precise issues, but they help a lot in fixing problems, and it's easier to send them to external people, maybe hire someone to get this done. I'd really appreciate your input here, because I only understand that Gitea has a general issue and that these PRs broke something in addition, but I don't really get what needs an urgent fix before releasing (or deploying) Gitea 1.15. > > Thank you. > > -- > 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/7057#issuecomment-881781999

GiteaMirror commented

@Flameborn commented on GitHub (Jul 17, 2021):

Hey @fnetX

The PR's @Jookia contributed basically add ARIA and some keyboard-related usability to Fomantic's dropdowns and accordions. Due to how Fomantic uses non-standard controls to represent these, Without proper ARIA markup, Gitea is completely unusable to a screen reader user. The PRs I mentioned do exactly this, i.e. remove the vendored controls, essentially reverting back to the inaccessible controls from upstream.

There is no need to open an issue, as you can see this described by @xingkong0113, as well as given examples where these controls are used.

Had there been interest upstream by Fomantic's developer(s), removing these improvements would not be an issue, as they themselves could add proper markup.

@Flameborn commented on GitHub (Jul 17, 2021): Hey @fnetX The PR's @Jookia contributed basically add ARIA and some keyboard-related usability to Fomantic's dropdowns and accordions. Due to how Fomantic uses non-standard controls to represent these, Without proper ARIA markup, Gitea is completely unusable to a screen reader user. The PRs I mentioned do exactly this, i.e. remove the vendored controls, essentially reverting back to the inaccessible controls from upstream. There is no need to open an issue, as you can see this described by @xingkong0113, as well as given examples where these controls are used. Had there been interest upstream by Fomantic's developer(s), removing these improvements would not be an issue, as they themselves could add proper markup.

GiteaMirror commented

@techknowlogick commented on GitHub (Jul 18, 2021):

FWIW Gitea has some modest funds we could hopefully put towards this, and I believe the same applies for Codeberg. I know Codeberg has discussed this, as well as have discussed searching for a firm that could do a study of Gitea, and also some remediation.

This of course is not a onetime fix, and then no one needs to be concerned with it every again, but rather an ongoing effort that is needed. So UI testing via CI, documentation for developers/maintainers of best practices when building Gitea, and even more than I could list at the moment.

@techknowlogick commented on GitHub (Jul 18, 2021): FWIW Gitea has some modest funds we could hopefully put towards this, and I believe the same applies for Codeberg. I know Codeberg has discussed this, as well as have discussed searching for a firm that could do a study of Gitea, and also some remediation. This of course is not a onetime fix, and then no one needs to be concerned with it every again, but rather an ongoing effort that is needed. So UI testing via CI, documentation for developers/maintainers of best practices when building Gitea, and even more than I could list at the moment.

GiteaMirror commented

@Jookia commented on GitHub (Jul 18, 2021):

You need to do UI testing using screen readers manually during
development. The same way you test UI with your eyes.

On Sun, Jul 18, 2021 at 02:36:22PM -0700, techknowlogick wrote:

FWIW Gitea has some modest funds we could hopefully put towards this, and I believe the same applies for Codeberg. I know Codeberg has discussed this, as well as have discussed searching for a firm that could do a study of Gitea, and also some remediation.

This of course is not a onetime fix, and then no one needs to be concerned with it every again, but rather an ongoing effort that is needed. So UI testing via CI, documentation for developers/maintainers of best practices when building Gitea, and even more than I could list at the moment.

--
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/7057#issuecomment-882119742

@Jookia commented on GitHub (Jul 18, 2021): You need to do UI testing using screen readers manually during development. The same way you test UI with your eyes. On Sun, Jul 18, 2021 at 02:36:22PM -0700, techknowlogick wrote: > FWIW Gitea has some modest funds we could hopefully put towards this, and I believe the same applies for Codeberg. I know Codeberg has discussed this, as well as have discussed searching for a firm that could do a study of Gitea, and also some remediation. > > This of course is not a onetime fix, and then no one needs to be concerned with it every again, but rather an ongoing effort that is needed. So UI testing via CI, documentation for developers/maintainers of best practices when building Gitea, and even more than I could list at the moment. > > -- > 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/7057#issuecomment-882119742

GiteaMirror commented

@mohe2015 commented on GitHub (Jul 19, 2021):

You need to do UI testing using screen readers manually during
development. The same way you test UI with your eyes.

There are accessibility check add-ons afaik and Firefox has a built-in tool which could also help catching easy issues

@mohe2015 commented on GitHub (Jul 19, 2021): > You need to do UI testing using screen readers manually during > development. The same way you test UI with your eyes. There are accessibility check add-ons afaik and Firefox has a built-in tool which could also help catching easy issues

GiteaMirror commented

@techknowlogick commented on GitHub (Jul 19, 2021):

You need to do UI testing using screen readers manually during
development. The same way you test UI with your eyes.

I completely agree, as mentioned the list I gave was not exhaustive. Manual testing would also certainly be included.

@techknowlogick commented on GitHub (Jul 19, 2021): > You need to do UI testing using screen readers manually during > development. The same way you test UI with your eyes. I completely agree, as mentioned the list I gave was not exhaustive. Manual testing would also certainly be included.

GiteaMirror commented

@ogomez92 commented on GitHub (Jul 19, 2021):

I'm sure many people here (me included) would be willing to do
testing, even if the developers were unable to test themselves. In
fact, it is the approach used in many companies. Develop and user
tests. I'm not familiar with Go nor the inner workings of Gitea, but I
can definitely test.

On 7/19/21, techknowlogick @.***> wrote:

You need to do UI testing using screen readers manually during
development. The same way you test UI with your eyes.

I completely agree, as mentioned the list I gave was not exhaustive. Manual
testing would also certainly be included.

--
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/7057#issuecomment-882255798

@ogomez92 commented on GitHub (Jul 19, 2021): I'm sure many people here (me included) would be willing to do testing, even if the developers were unable to test themselves. In fact, it is the approach used in many companies. Develop and user tests. I'm not familiar with Go nor the inner workings of Gitea, but I can definitely test. On 7/19/21, techknowlogick ***@***.***> wrote: >> You need to do UI testing using screen readers manually during >> development. The same way you test UI with your eyes. > > I completely agree, as mentioned the list I gave was not exhaustive. Manual > testing would also certainly be included. > > -- > 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/7057#issuecomment-882255798

GiteaMirror commented

@charlag commented on GitHub (Jul 19, 2021):

As it stands, the merge of #15951 and #15193 currently break the very minimal screen reader support. Please do not upgrade to https://github.com/go-gitea/gitea/tree/v1.15.0-rc1 (or above) if you use screen reading software.

Knowing that Gitea is used and relied on by keyboard/screen reader users, yet still merging accessibility-breaking changes is a very unwise move, especially because, to my knowledge, there is nothing else that provides the same (or even a similar) feature set as Gitea. I understand that backward compatibility requires a lot of effort to maintain, but without it, you are essentially ignoring users (by choice) who have to rely on screen reading software, which is not by choice, by the way. Please strongly reconsider this, especially @silverwind and @techknowlogick. We don't just lose some #a11y, we lose most of what's been there. In fact, there have been no other accessibility improvements made other than these two, as far as I know.

Many modern UI toolkits have ARIA-enabled controls these days, or due to their design, they require very minimal ARIA/javascript to make their controls keyboard/screen reader accessible.

I still believe that since there is no interest whatsoever in accessibility upstream, dropping Fomantic and switching to something like Bootstrap, React, etc, is the way forward in ensuring that Gitea can be accessed equally. Until this is done, however, blind/visually impaired users are currently left in the dark (no pun intended).

I am currently trying to look into the issue and I'm trying to find out what exactly is broken. I'm currently testing with Orca as the first step.

So far I've found that dropdown does not work. I suspect it must be completely re-done:

it automatically expands when you focus on it and it is not announced at all
it's impossible to select dropdown items with keyboard. Tabbing switches to the useless inner button of the dropdown instead (as a note to developers: even if you don't test with screen reader you can still try to use keyboard to see if things work)

Hovewer I do not see the problem with #15951 ? It uses details/summary elements which are pretty well supported by screen readers I believe.

@charlag commented on GitHub (Jul 19, 2021): > As it stands, the merge of #15951 and #15193 currently break the very minimal screen reader support. Please do not upgrade to https://github.com/go-gitea/gitea/tree/v1.15.0-rc1 (or above) if you use screen reading software. > > Knowing that Gitea is used and relied on by keyboard/screen reader users, yet still merging accessibility-breaking changes is a very unwise move, especially because, to my knowledge, there is nothing else that provides the same (or even a similar) feature set as Gitea. I understand that backward compatibility requires a lot of effort to maintain, but without it, you are essentially ignoring users (by choice) who have to rely on screen reading software, which is not by choice, by the way. Please strongly reconsider this, especially @silverwind and @techknowlogick. We don't just lose _some_ #a11y, we lose _most_ of what's been there. In fact, there have been no other accessibility improvements made other than these two, as far as I know. > > Many modern UI toolkits have ARIA-enabled controls these days, or due to their design, they require very minimal ARIA/javascript to make their controls keyboard/screen reader accessible. > > I still believe that since there is no interest whatsoever in accessibility upstream, dropping Fomantic and switching to something like Bootstrap, React, etc, is the way forward in ensuring that Gitea can be accessed equally. Until this is done, however, blind/visually impaired users are currently left in the dark (no pun intended). I am currently trying to look into the issue and I'm trying to find out what exactly is broken. I'm currently testing with Orca as the first step. So far I've found that dropdown does not work. I suspect it must be completely re-done: - it automatically expands when you focus on it and it is not announced at all - it's impossible to select dropdown items with keyboard. Tabbing switches to the useless inner button of the dropdown instead (as a note to developers: even if you don't test with screen reader you can still try to use keyboard to see if things work) Hovewer I do not see the problem with #15951 ? It uses details/summary elements which are pretty well supported by screen readers I believe.

GiteaMirror commented

@Jookia commented on GitHub (Jul 19, 2021):

Dropdowns did work, now they're broken again.

Details/summary elements are not accordions.

@Jookia commented on GitHub (Jul 19, 2021): Dropdowns did work, now they're broken again. Details/summary elements are not accordions.

GiteaMirror commented

@Flameborn commented on GitHub (Jul 19, 2021):

@charlag, thank you very much for looking into this.

Hovewer I do not see the problem with #15951 ?

You are right. I was under the impression that this would be a Fomantic custom control, but this is browser-native, which works fine.

@Flameborn commented on GitHub (Jul 19, 2021): @charlag, thank you very much for looking into this. > Hovewer I do not see the problem with #15951 ? You are right. I was under the impression that this would be a Fomantic custom control, but this is browser-native, which works fine.

GiteaMirror commented

@Flameborn commented on GitHub (Jul 19, 2021):

Details/summary elements are not accordions.
From an #a11y point of view, they work, but technically they are not meant to be used as accordions, you are right. This is more of a best practices issue, however, similarly to how buttons should not be used to link pages, especially if they are not styled to look like buttons.

@Flameborn commented on GitHub (Jul 19, 2021): > Details/summary elements are not accordions. From an #a11y point of view, they work, but technically they are not meant to be used as accordions, you are right. This is more of a best practices issue, however, similarly to how buttons should not be used to link pages, especially if they are not styled to look like buttons.

GiteaMirror commented

@charlag commented on GitHub (Jul 19, 2021):

@Flameborn I think there's a disparity between how it was supposed to be used and how it is used in practice. What I am interested in right now is making it work and dropdowns are completely broken so I propose to focus on that.

@charlag commented on GitHub (Jul 19, 2021): @Flameborn I think there's a disparity between how it was supposed to be used and how it is used in practice. What I am interested in right now is making it work and dropdowns are completely broken so I propose to focus on that.

GiteaMirror commented

@Flameborn commented on GitHub (Jul 19, 2021):

@Flameborn I think there's a disparity between how it was supposed to be used and how it is used in practice. What I am interested in right now is making it work and dropdowns are completely broken so I propose to focus on that.

You are right, best practices in this case are less important (especially if they are still accessible natively) than something that is completely unusable. Since dropdowns are used everywhere, even on the installation page, having that fixed is probably the most important thing for v1.15. Other, less important things can be focused on later down the line.

@Flameborn commented on GitHub (Jul 19, 2021): > @Flameborn I think there's a disparity between how it was supposed to be used and how it is used in practice. What I am interested in right now is making it work and dropdowns are completely broken so I propose to focus on that. You are right, best practices in this case are less important (especially if they are still accessible natively) than something that is completely unusable. Since dropdowns are used everywhere, even on the installation page, having that fixed is probably the most important thing for v1.15. Other, less important things can be focused on later down the line.

GiteaMirror commented

@charlag commented on GitHub (Jul 19, 2021):

I think there are two options:

Using native <select>/<option>. It looks decent when collapsed but doesn't look as good when expanding it etc. This is obviously the easiest option.
Override dropdown like it was suggested here https://github.com/fomantic/Fomantic-UI/issues/1332#issuecomment-588079479 and how it was used before #15193. This is a bigger investment and that's what @Jookia already did once and is properly better equipped to do than me.

I know, I know, "the whole UI must be rewritten", unfortunately this doesn't help right now and something must be done right now.

I could try to hack together option 2 again. It basically needs:

Click handler for opening the dropdown and selecting the first item
Click handler for dropdown items
Blur handler for closing the dropdown when focus is lost
Animations for both

I want to get some feedback from maintainers before I will proceed with either.

@charlag commented on GitHub (Jul 19, 2021): I think there are two options: 1. Using native `<select>`/`<option>`. It looks decent when collapsed but doesn't look as good when expanding it etc. This is obviously the easiest option. 2. Override dropdown like it was suggested here https://github.com/fomantic/Fomantic-UI/issues/1332#issuecomment-588079479 and how it was used before #15193. This is a bigger investment and that's what @Jookia already did once and is properly better equipped to do than me. I know, I know, "the whole UI must be rewritten", unfortunately this doesn't help right now and something must be done right now. I could try to hack together option 2 again. It basically needs: 1. Click handler for opening the dropdown and selecting the first item 2. Click handler for dropdown items 3. Blur handler for closing the dropdown when focus is lost 4. Animations for both I want to get some feedback from maintainers before I will proceed with either.

GiteaMirror commented

@charlag commented on GitHub (Jul 19, 2021):

For how <select> can work go to https://github.com/settings/profile and check language/email dropdown there.

@charlag commented on GitHub (Jul 19, 2021): For how `<select>` can work go to https://github.com/settings/profile and check language/email dropdown there.

GiteaMirror commented

https://jsfiddle.net/lubber/cupwk8sh/75/

@lubber-de commented on GitHub (Jul 19, 2021):

As discussed in https://github.com/fomantic/Fomantic-UI/issues/1332#issuecomment-882465723, here is some draft of ui native dropdown to a select tag i tried some time ago. Don't know, if this helps the project at all.

@lubber-de commented on GitHub (Jul 19, 2021): As discussed in https://github.com/fomantic/Fomantic-UI/issues/1332#issuecomment-882465723, here is some draft of `ui native dropdown` to a `select` tag i tried some time ago. Don't know, if this helps the project at all. https://jsfiddle.net/lubber/cupwk8sh/75/

GiteaMirror commented

@silverwind commented on GitHub (Jul 20, 2021):

Native <select> works in some cases but looks ugly and Gitea has some dropdowns that have HTML content which requires a different solution.

Personally, I like using tippy.js which builds on popper.js for its flawless positioning of overlay content. I think anything based on popper.js would be fine. Fomantic certainly has issues with positioning dropdown contents in some cases.

@silverwind commented on GitHub (Jul 20, 2021): Native `<select>` works in some cases but looks ugly and Gitea has some dropdowns that have HTML content which requires a different solution. Personally, I like using [tippy.js](https://atomiks.github.io/tippyjs/#html-content) which builds on popper.js for its flawless positioning of overlay content. I think anything based on popper.js would be fine. Fomantic certainly has issues with positioning dropdown contents in some cases.

GiteaMirror commented

@Flameborn commented on GitHub (Jul 20, 2021):

Looking at their demo, the dropdowns seem to show up as a collapsed/expanded button, as well as focusable buttons as dropdown items to a screen reader.

While this does not have a native feel, e.g. items can't be focused with the arrow keys once the dropdown is expanded, items have a defined tabIndex. If this ends up being used, it's still a huge improvement over the Fomantic dropdowns.

@Flameborn commented on GitHub (Jul 20, 2021): Looking at their demo, the dropdowns seem to show up as a collapsed/expanded button, as well as focusable buttons as dropdown items to a screen reader. While this does not have a native feel, e.g. items can't be focused with the arrow keys once the dropdown is expanded, items have a defined *tabIndex*. If this ends up being used, it's still a huge improvement over the Fomantic dropdowns.

GiteaMirror commented

@lafriks commented on GitHub (Jul 20, 2021):

Or we could just not use fomantic-ui dropdown JavaScript but replace it with own built Vue component (just with correctly added aria attributes etc) something like I did with branch selection somewhere if I remember correctly. But still using fomantic css and html elements as needed

For reference: ec357833bc/web_src/js/index.js (L3495)

@lafriks commented on GitHub (Jul 20, 2021): Or we could just not use fomantic-ui dropdown JavaScript but replace it with own built Vue component (just with correctly added aria attributes etc) something like I did with branch selection somewhere if I remember correctly. But still using fomantic css and html elements as needed For reference: https://github.com/go-gitea/gitea/blob/ec357833bcfc90860331f956a811ecbf45df47aa/web_src/js/index.js#L3495

GiteaMirror commented

@silverwind commented on GitHub (Jul 21, 2021):

Yes I think we should do a custom dropdown initialization. I quite like how Github has done it using <details> and <summary> elements because that works even with JavaScript disabled, so it can be probably be done completely in HTML with no JS/Vue involved. For proper menu positioning, JS might be unavoidable thought.

It should probably also distinguish between select-style dropdowns and more complex ones like the review dropdown.

@silverwind commented on GitHub (Jul 21, 2021): Yes I think we should do a custom dropdown initialization. I quite like how Github has done it using `<details>` and `<summary>` elements because that works even with JavaScript disabled, so it can be probably be done completely in HTML with no JS/Vue involved. For proper menu positioning, JS might be unavoidable thought. It should probably also distinguish between select-style dropdowns and more complex ones like the review dropdown.

GiteaMirror commented

@charlag commented on GitHub (Jul 23, 2021):

I've built dropdowns in other projects before but I have no experience with either Vue or jQuery for that matter. Anyone wants to step in and make one? From what I understand is that @silverwind implies that PR might get included and not just lay around.
@Codeberg-org would really like to solve this and they might even sponsor this work so would be nice if there's a competent champion for this.

Oh and btw tippy looks like a library for tooltips, not for dropdowns.

@charlag commented on GitHub (Jul 23, 2021): I've built dropdowns in other projects before but I have no experience with either Vue or jQuery for that matter. Anyone wants to step in and make one? From what I understand is that @silverwind implies that PR might get included and not just lay around. @Codeberg-org would really like to solve this and they might even sponsor this work so would be nice if there's a competent champion for this. Oh and btw tippy looks like a library for tooltips, not for dropdowns.

GiteaMirror commented

@silverwind commented on GitHub (Jul 27, 2021):

Oh and btw tippy looks like a library for tooltips, not for dropdowns.

It's labeled as "Tooltip, popover, dropdown, and menu library" so I think it's still suitable, and sufficiently lightweight at that.

@silverwind commented on GitHub (Jul 27, 2021): > Oh and btw tippy looks like a library for tooltips, not for dropdowns. It's [labeled](https://github.com/atomiks/tippyjs) as "Tooltip, popover, dropdown, and menu library" so I think it's still suitable, and sufficiently [lightweight](https://bundlephobia.com/package/tippy.js@6.3.1) at that.

GiteaMirror commented

@charlag commented on GitHub (Jul 27, 2021):

Yeah except it doesn't create anything focusable afaik

@charlag commented on GitHub (Jul 27, 2021): Yeah except it doesn't create anything focusable afaik

GiteaMirror commented

@Flameborn commented on GitHub (Jul 27, 2021):

It does, see my previous comment above. In a dropdown, items are actual buttons. It’s not perfect, but it works much better than what we currently have in RC1.

On 2021. Jul 27., at 18:12, Ivan Kupalov @.***> wrote:

Yeah except it doesn't create anything focusable afaik

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/7057#issuecomment-887645237, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4AZZVPRIDPP7VRNJOTTZ3LINANCNFSM4HPYFNCQ.

@Flameborn commented on GitHub (Jul 27, 2021): It does, see my previous comment above. In a dropdown, items are actual buttons. It’s not perfect, but it works much better than what we currently have in RC1. > On 2021. Jul 27., at 18:12, Ivan Kupalov ***@***.***> wrote: > > > Yeah except it doesn't create anything focusable afaik > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <https://github.com/go-gitea/gitea/issues/7057#issuecomment-887645237>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4AZZVPRIDPP7VRNJOTTZ3LINANCNFSM4HPYFNCQ>. >

GiteaMirror commented

2025-11-02 05:11:10 -06:00

@fnetX commented on GitHub (Jul 28, 2021):

Does the Gitea team consider the broken accessibility as release critical for 1.15? Like, does it matter if the software is not usable for some users at all? If so, you might want to add an issue to the milestone to make sure some fix makes it in! Shall I open a new one to explicitly track the accessibility regressions in 1.15 and keep this as a general discussion?

I don't really know how to best move on. Paying someone for a quick fix is surely possible, but it will be hard to motivate someone if there is no guarantee that the fixes aren't broken again, as it happened to the last ones, and when there is no overall strategy on how to take care of accessibility in the future.
I perfectly understand that some people are not willing to help in this situation, and even money won't help here.

If we don't manage to move forward here, what about having a brief meeting and discussing some next steps, or using some chat group (e.g. Matrix) to discuss the matter? We also have some testers around who might be interested to join the discussion and help in identifying the issues and confirming the fixes.

BTW, I like the details/summary approach without requiring JavaScript for some basic functionality, this sounds good, tippy doesn't work without JS. But I don't really want to force something on UI people, I don't have much knowledge of Web UI.

@fnetX commented on GitHub (Jul 28, 2021): Does the Gitea team consider the broken accessibility as release critical for 1.15? Like, does it matter if the software is not usable for some users at all? If so, you might want to add an issue to the milestone to make sure some fix makes it in! Shall I open a new one to explicitly track the accessibility regressions in 1.15 and keep this as a general discussion? I don't really know how to best move on. Paying someone for a quick fix is surely possible, but it will be hard to motivate someone if there is no guarantee that the fixes aren't broken again, as it happened to the last ones, and when there is no overall strategy on how to take care of accessibility in the future. I perfectly understand that some people are not willing to help in this situation, and even money won't help here. If we don't manage to move forward here, what about having a brief meeting and discussing some next steps, or using some chat group (e.g. Matrix) to discuss the matter? We also have some testers around who might be interested to join the discussion and help in identifying the issues and confirming the fixes. --- BTW, I like the details/summary approach without requiring JavaScript for some basic functionality, this sounds good, tippy doesn't work without JS. But I don't really want to force something on UI people, I don't have much knowledge of Web UI.

GiteaMirror commented

@zeripath commented on GitHub (Jul 29, 2021):

The vendored dropdown that contained Jookia's fixes was removed in #15193 due to it becoming incompatible with fomantic and then breaking everything. The decision was made to abandon it - an action I had prevented twice before but this time I was unable to spend time updating it and had been unable to understand what it was doing.

This was a course of action I was disappointed in but I hoped that it might actually spur someone to actually propose a more stable solution or even just re-port jookia's changes to the latest fomantic for Gitea and repropose them.

This has not happened and instead we have had another 30 comments not really getting anywhere.

So can we please take a more constructive course?

I'll take a look at Jookia's patch again and try to reapply them to fomantic's dropdown.
However, clearly fomantic's dropdowns aren't going to work. Jookia's fix although comprehensive is fundamentally not a maintainable solution for us without further help from Jookia.
I have been unable to find a concise explanation of what would work or had one proposed. No explanation of why what is currently present doesn't work or steps to fix the problem.

Can anyone point to an actual example of a dropdown that will work? Or propose incremental changes to improve Gitea's accessibility?

@zeripath commented on GitHub (Jul 29, 2021): The vendored dropdown that contained Jookia's fixes was removed in #15193 due to it becoming incompatible with fomantic and then breaking everything. The decision was made to abandon it - an action I had prevented twice before but this time I was unable to spend time updating it and had been unable to understand what it was doing. This was a course of action I was disappointed in but I hoped that it might actually spur someone to actually propose a more stable solution or even just re-port jookia's changes to the latest fomantic for Gitea and repropose them. This has not happened and instead we have had another 30 comments not really getting anywhere. --- So can we please take a more constructive course? * I'll take a look at Jookia's patch again and try to reapply them to fomantic's dropdown. * However, clearly fomantic's dropdowns aren't going to work. Jookia's fix although comprehensive is fundamentally not a maintainable solution for us without further help from Jookia. * I have been unable to find a concise explanation of what would work or had one proposed. No explanation of why what is currently present doesn't work or steps to fix the problem. Can anyone point to an actual example of a dropdown that will work? Or propose incremental changes to improve Gitea's accessibility?

GiteaMirror commented

2025-11-02 05:11:10 -06:00

@charlag commented on GitHub (Jul 29, 2021):

The vendored dropdown that contained Jookia's fixes was removed in #15193 due to it becoming incompatible with fomantic and then breaking everything. The decision was made to abandon it - an action I had prevented twice before but this time I was unable to spend time updating it and had been unable to understand what it was doing.

This was a course of action I was disappointed in but I hoped that it might actually spur someone to actually propose a more stable solution or even just re-port jookia's changes to the latest fomantic for Gitea and repropose them.

This has not happened and instead we have had another 30 comments not really getting anywhere.

So can we please take a more constructive course?
* I'll take a look at Jookia's patch again and try to reapply them to fomantic's dropdown.

* However, clearly fomantic's dropdowns aren't going to work. Jookia's fix although comprehensive is fundamentally not a maintainable solution for us without further help from Jookia.

* I have been unable to find a concise explanation of what would work or had one proposed. No explanation of why what is currently present doesn't work or steps to fix the problem.
Can anyone point to an actual example of a dropdown that will work? Or propose incremental changes to improve Gitea's accessibility?

Dropdown cannot be opened using keyboard, you cannot close of using keyboard, you cannot select items using keyboard. That is the problem. Once it's done it roll work with screen readers.

We have acessible dropdowns at mail.tutanota.com (try "change color theme" under more) if you need an example. It's done on top of mithril but there's nothing really special about it.

@charlag commented on GitHub (Jul 29, 2021): > The vendored dropdown that contained Jookia's fixes was removed in #15193 due to it becoming incompatible with fomantic and then breaking everything. The decision was made to abandon it - an action I had prevented twice before but this time I was unable to spend time updating it and had been unable to understand what it was doing. > > This was a course of action I was disappointed in but I hoped that it might actually spur someone to actually propose a more stable solution or even just re-port jookia's changes to the latest fomantic for Gitea and repropose them. > > This has not happened and instead we have had another 30 comments not really getting anywhere. > > So can we please take a more constructive course? > > * I'll take a look at Jookia's patch again and try to reapply them to fomantic's dropdown. > > * However, clearly fomantic's dropdowns aren't going to work. Jookia's fix although comprehensive is fundamentally not a maintainable solution for us without further help from Jookia. > > * I have been unable to find a concise explanation of what would work or had one proposed. No explanation of why what is currently present doesn't work or steps to fix the problem. > > > Can anyone point to an actual example of a dropdown that will work? Or propose incremental changes to improve Gitea's accessibility? Dropdown cannot be opened using keyboard, you cannot close of using keyboard, you cannot select items using keyboard. That is the problem. Once it's done it roll work with screen readers. We have acessible dropdowns at mail.tutanota.com (try "change color theme" under more) if you need an example. It's done on top of mithril but there's nothing really special about it.

GiteaMirror commented

2025-11-02 05:11:10 -06:00

@techknowlogick commented on GitHub (Jul 29, 2021):

Dropdown cannot be opened using keyboard, you cannot close of using keyboard, you cannot select items using keyboard. That is the problem. Once it's done it roll work with screen readers.

This is not true, by testing try.gitea.io keyboard navigation works and I can open/close dropdowns, and even navigate to/select links in the list, however VoiceOver doesn't recognize that the dropdown is open and won't read out things.

This screenshot is from keyboard navigation, it shows that I've opened the dropdown, and am able to hover over (and can open the link), however you'll note that the voiceover select sticks with the user icon at the top of the dropdown.

I've copied Jookia's changes to a branch of fomantic, however @zeripath is looking at how to get it working with jQuery. We (the Gitea project), are happy to pay a nominal amount to 1. Jookia for existing work done, 2. Person who gets an acceptable PR merged to fomantic, and 3. the fomantic maintainers to assist with getting our dropdown's working with screenreaders.

Shortterm we would be happy accept a PR that fixes issues into the 1.15 release, as it is considered bugs and we backport bugs. Longterm a study on accessibility needs to be done and remedial work based on the outcome of that report (as well as likely a change in UI framework).

@techknowlogick commented on GitHub (Jul 29, 2021): > Dropdown cannot be opened using keyboard, you cannot close of using keyboard, you cannot select items using keyboard. That is the problem. Once it's done it roll work with screen readers. This is not true, by testing try.gitea.io keyboard navigation works and I can open/close dropdowns, and even navigate to/select links in the list, however VoiceOver doesn't recognize that the dropdown is open and won't read out things. This screenshot is from keyboard navigation, it shows that I've opened the dropdown, and am able to hover over (and can open the link), however you'll note that the voiceover select sticks with the user icon at the top of the dropdown. ![Screenshot showing voiceover keeps on the user icon in dropdown while keyboard is able to select an item in the list](https://user-images.githubusercontent.com/164197/127567173-42ad9ed6-c566-4b26-ad87-6ec46f59e5f0.png) I've copied Jookia's changes to a [branch of fomantic](https://github.com/techknowlogick/Fomantic-UI/commit/436f3a76509554e462ed989359f576823276e22a), however @zeripath is looking at how to get it working with jQuery. We (the Gitea project), are happy to pay a nominal amount to 1. Jookia for existing work done, 2. Person who gets an acceptable PR merged to fomantic, and 3. the fomantic maintainers to assist with getting our dropdown's working with screenreaders. Shortterm we would be happy accept a PR that fixes issues into the 1.15 release, as it is considered bugs and we backport bugs. Longterm a study on accessibility needs to be done and remedial work based on the outcome of that report (as well as likely a change in UI framework).

GiteaMirror commented

@charlag commented on GitHub (Jul 29, 2021):

Dropdown cannot be opened using keyboard, you cannot close of using keyboard, you cannot select items using keyboard. That is the problem. Once it's done it roll work with screen readers.

This is not true, by testing try.gitea.io keyboard navigation works and I can open/close dropdowns, and even navigate to/select links in the list, however VoiceOver doesn't recognize that the dropdown is open and won't read out things.

This screenshot is from keyboard navigation, it shows that I've opened the dropdown, and am able to hover over (and can open the link), however you'll note that the voiceover select sticks with the user icon at the top of the dropdown.

I've copied Jookia's changes to a branch of fomantic, however @zeripath is looking at how to get it working with jQuery. We (the Gitea project), are happy to pay a nominal amount to 1. Jookia for existing work done, 2. Person who gets an acceptable PR merged to fomantic, and 3. the fomantic maintainers to assist with getting our dropdown's working with screenreaders.

Shortterm we would be happy accept a PR that fixes issues into the 1.15 release, as it is considered bugs and we backport bugs. Longterm a study on accessibility needs to be done and remedial work based on the outcome of that report (as well as likely a change in UI framework).

I'm sorry that I missed that, thanks for actually checking.

If opening the dropdown works I think it should be enough to just focus the first element after that and return focus back once dropdown is closed.

@charlag commented on GitHub (Jul 29, 2021): > > Dropdown cannot be opened using keyboard, you cannot close of using keyboard, you cannot select items using keyboard. That is the problem. Once it's done it roll work with screen readers. > > This is not true, by testing try.gitea.io keyboard navigation works and I can open/close dropdowns, and even navigate to/select links in the list, however VoiceOver doesn't recognize that the dropdown is open and won't read out things. > > This screenshot is from keyboard navigation, it shows that I've opened the dropdown, and am able to hover over (and can open the link), however you'll note that the voiceover select sticks with the user icon at the top of the dropdown. > > ![Screenshot showing voiceover keeps on the user icon in dropdown while keyboard is able to select an item in the list](https://user-images.githubusercontent.com/164197/127567173-42ad9ed6-c566-4b26-ad87-6ec46f59e5f0.png) > > I've copied Jookia's changes to a [branch of fomantic](https://github.com/techknowlogick/Fomantic-UI/commit/436f3a76509554e462ed989359f576823276e22a), however @zeripath is looking at how to get it working with jQuery. We (the Gitea project), are happy to pay a nominal amount to 1. Jookia for existing work done, 2. Person who gets an acceptable PR merged to fomantic, and 3. the fomantic maintainers to assist with getting our dropdown's working with screenreaders. > > Shortterm we would be happy accept a PR that fixes issues into the 1.15 release, as it is considered bugs and we backport bugs. Longterm a study on accessibility needs to be done and remedial work based on the outcome of that report (as well as likely a change in UI framework). I'm sorry that I missed that, thanks for actually checking. If opening the dropdown works I think it should be enough to just focus the first element after that and return focus back once dropdown is closed.

GiteaMirror commented

@Jookia commented on GitHub (Jul 30, 2021):

The actual process for properly fixing things is this:

Find a broken widget
Decide what the widget actually is in the ARIA spec
Give it corrected ARIA markup in HTML
Provide hooks for Fomantic's JS

All UI developers going forward will have to understand ARIA to write Gitea UI code.

Why is this?

Semantic-UI and Fomantic-UI are too low level to add ARIA accessibility natively.
They do not provide widgets, they provide components that Gitea uses to make its own ad-hoc widgets.
Gitea is the one making widgets, so it needs to implement the accessibility code itself.
Maybe down the line you could take this experience and turn it in to a Fomantic widget library or something.

The best solution is to probably start rewriting individual templates to use Bootstrap or something that provides clearly defined widgets.

Edit: The existing Fomantic code I wrote just takes a guess at what widget is which, and actually uses invalid ARIA roles.

@Jookia commented on GitHub (Jul 30, 2021): The actual process for properly fixing things is this: - Find a broken widget - Decide what the widget actually is in the ARIA spec - Give it corrected ARIA markup in HTML - Provide hooks for Fomantic's JS All UI developers going forward will have to understand ARIA to write Gitea UI code. Why is this? Semantic-UI and Fomantic-UI are too low level to add ARIA accessibility natively. They do not provide widgets, they provide components that Gitea uses to make its own ad-hoc widgets. Gitea is the one making widgets, so it needs to implement the accessibility code itself. Maybe down the line you could take this experience and turn it in to a Fomantic widget library or something. The best solution is to probably start rewriting individual templates to use Bootstrap or something that provides clearly defined widgets. Edit: The existing Fomantic code I wrote just takes a guess at what widget is which, and actually uses invalid ARIA roles.

GiteaMirror commented

@zeripath commented on GitHub (Jul 30, 2021):

@Jookia I'm more than happy to add ARIA codes to our templates. I'd be more than happy to learn what ARIA requires too.

But ...

The documentation for this stuff is absolutely terrible and is full of contradictions. It's all rather specific to each specific case.

As I wrote 1.5 years ago:

We need to learn the patterns that make things accessible.

I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help.

The way we will learn this is through examples of working practices.

If you are available I'd like to go through that dropdown patch in detail on a different - hopefully more productive - thread which I'll link soon. I think a lot of it could be done using fomantic hooks and template changes and I could do with understanding why you've made certain changes.

@zeripath commented on GitHub (Jul 30, 2021): @Jookia I'm more than happy to add ARIA codes to our templates. I'd be more than happy to learn what ARIA requires too. But ... The documentation for this stuff is absolutely terrible and is full of contradictions. It's all rather specific to each specific case. As I wrote 1.5 years ago: > We need to learn the patterns that make things accessible. > > I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help. The way we will learn this is through examples of working practices. --- If you are available I'd like to go through that dropdown patch in detail on a different - hopefully more productive - thread which I'll link soon. I think a lot of it could be done using fomantic hooks and template changes and I could do with understanding why you've made certain changes.

GiteaMirror commented

@Jookia commented on GitHub (Jul 30, 2021):

@Jookia I'm more than happy to add ARIA codes to our templates. I'd be more than happy to learn what ARIA requires too.

But ...

The documentation for this stuff is absolutely terrible and is full of contradictions. It's all rather specific to each specific case.

This is what I've worked with: https://www.w3.org/TR/wai-aria-practices-1.2/
As well as googling what roles specifically are.
The dropdown I made uses the 'menu or menu bar' section when it should be using a 'listbox'.

As I wrote 1.5 years ago:

We need to learn the patterns that make things accessible.
I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help.

The way we will learn this is through examples of working practices.

wai-aria-practices is full of examples complete with Javascript:
https://www.w3.org/TR/wai-aria-practices-1.2/examples/listbox/listbox-collapsible.html

If you are available I'd like to go through that dropdown patch in detail on a different - hopefully more productive - thread which I'll link soon. I think a lot of it could be done using fomantic hooks and template changes and I could do with understanding why you've made certain changes.

Sure, I'll try.

@Jookia commented on GitHub (Jul 30, 2021): > @Jookia I'm more than happy to add ARIA codes to our templates. I'd be more than happy to learn what ARIA requires too. > > But ... > > The documentation for this stuff is absolutely terrible and is full of contradictions. It's all rather specific to each specific case. This is what I've worked with: https://www.w3.org/TR/wai-aria-practices-1.2/ As well as googling what roles specifically are. The dropdown I made uses the 'menu or menu bar' section when it should be using a 'listbox'. > As I wrote 1.5 years ago: > > > We need to learn the patterns that make things accessible. > > I genuinely want this to improve but have no time to learn how to do it. You clearly have the skills to do this so please don't disappear. We need your help. > > The way we will learn this is through examples of working practices. wai-aria-practices is full of examples complete with Javascript: https://www.w3.org/TR/wai-aria-practices-1.2/examples/listbox/listbox-collapsible.html > If you are available I'd like to go through that dropdown patch in detail on a different - hopefully more productive - thread which I'll link soon. I think a lot of it could be done using fomantic hooks and template changes and I could do with understanding why you've made certain changes. Sure, I'll try.

GiteaMirror commented

@Jookia commented on GitHub (Jul 30, 2021):

I initially wrote a very, very long reply here about what Gitea should do next, but really what Gitea needs to do is a very basic accessibility audit. Things like icons or images without alt text, bad contrast, what which widgets are in ARIA terms, how things actually sound or work. This isn't that big a task, it just requires a list of every page template, and writing down notes in an issue, then drawing conclusions about the problem areas and how to move forward from there.

This would move things from 'Gitea has an accessibility problem' to 'Gitea has certain problems'. Then you can start moving to classify the problems and work on ways to systemically fix them.

@Jookia commented on GitHub (Jul 30, 2021): I initially wrote a very, very long reply here about what Gitea should do next, but really what Gitea needs to do is a very basic accessibility audit. Things like icons or images without alt text, bad contrast, what which widgets are in ARIA terms, how things actually sound or work. This isn't that big a task, it just requires a list of every page template, and writing down notes in an issue, then drawing conclusions about the problem areas and how to move forward from there. This would move things from 'Gitea has an accessibility problem' to 'Gitea has certain problems'. Then you can start moving to classify the problems and work on ways to systemically fix them.

GiteaMirror commented

@techknowlogick commented on GitHub (Jul 30, 2021):

@Jookia We (myself & the project) agree. I was going to reply with the following to my email from earlier, but might as well put it here instead. We have been researching accessibility vendors to complete an audit like you have mentioned above, and just today have reached out to see if we can hire one. From that report, like you said, we will have explicit issues to resolve, but we can also create best practices for going forward.

Thank you for creating that original PR before, but also your advocacy to make Gitea better software for everyone.

@techknowlogick commented on GitHub (Jul 30, 2021): @Jookia We (myself & the project) agree. I was going to reply with the following to my email from earlier, but might as well put it here instead. We have been researching accessibility vendors to complete an audit like you have mentioned above, and just today have reached out to see if we can hire one. From that report, like you said, we will have explicit issues to resolve, but we can also create best practices for going forward. Thank you for creating that original PR before, but also your advocacy to make Gitea better software for everyone.

GiteaMirror commented

@Jookia commented on GitHub (Jul 30, 2021):

I originally wrote a long message before my last comment but deleted it since it wasn't really that important, but I might as well paste it here anyway:

There's mainly three things I think the project needs to get widgets fixed:

The first is a widget factory page. This would contain reference HTML for each type of widget Gitea uses, and other HTML stuff like forms. This would allow much easier testing of accessibility features- at least for code on this page. This applies not just to ARIA but things like WCAG accessibility, etc. Just things whose accessibility is affected by code like HTML/CSS/JS. Fixing accessibility bugs would then become for the most part focused on this page as a test platform, assuming it contains each type/permutation of the widgets.

The second is to refactor ALL HTML to use reference HTML. There's a variety of ways to do this, the preferred way would be using some form of templates that get compiled in to the reference HTML. I think this is how server-side React tends to do things. The other way I can think of would be having a linter that will warn when templates don't match reference HTML, or at least how we decide things should be. A linter might actually be better for building habits and allowing more flexible systems, but it really depends on what people can actually build. It would also warn about missing alt tags on images and things like that.

The third is CI. AFAIK there's no CI solutions for testing accessibility things since a lot of it is human based. But I think there's two things you'd want to implement: The first is a WebDriver that crawls pages and lints widgets for ARIA properties to make sure they're actual reference/working widgets, to some extent. The second is a Orca test for the widgets page, which would basically mean implementing something like https://github.com/GNOME/orca/blob/master/test/keystrokes/firefox/line_nav_hidden_float.py

In the end, the best tools are the ones that people will use, so it's really up to the Gitea developers to give input on what would build in to their workflow and how to handle a refactor. Starting with just dropdowns would be a decent exercise for this. The main busywork comes from fixing up the HTML to use specific widgets.

The actual game plan for this involves creating widgets that are mappable to ARIA widgets, and code that adds ARIA support code for them. Ideally this would build on top of Fomantic's components as some kind of glue to make widgets, so instead of a 'dropdown' component used in various places, you'd have high level widgets like 'listbox'. How this gets written and made varies depending on whether you want this to end up as part of Fomantic and maintain that, or just as some template code in Gitea. Maybe it could go in another package altogether? I don't know.

The process would probably go like this:

Go through all the Gitea pages and identify what types of widgets you have and what they do
Figure out a mapping between those and some high-level widgets you'd make that support ARIA
Identify and replace Fomantic widgets with ARIA-aware widgets incrementally

@Jookia commented on GitHub (Jul 30, 2021): I originally wrote a long message before my last comment but deleted it since it wasn't really that important, but I might as well paste it here anyway: There's mainly three things I think the project needs to get widgets fixed: The first is a widget factory page. This would contain reference HTML for each type of widget Gitea uses, and other HTML stuff like forms. This would allow much easier testing of accessibility features- at least for code on this page. This applies not just to ARIA but things like WCAG accessibility, etc. Just things whose accessibility is affected by code like HTML/CSS/JS. Fixing accessibility bugs would then become for the most part focused on this page as a test platform, assuming it contains each type/permutation of the widgets. The second is to refactor ALL HTML to use reference HTML. There's a variety of ways to do this, the preferred way would be using some form of templates that get compiled in to the reference HTML. I think this is how server-side React tends to do things. The other way I can think of would be having a linter that will warn when templates don't match reference HTML, or at least how we decide things should be. A linter might actually be better for building habits and allowing more flexible systems, but it really depends on what people can actually build. It would also warn about missing alt tags on images and things like that. The third is CI. AFAIK there's no CI solutions for testing accessibility things since a lot of it is human based. But I think there's two things you'd want to implement: The first is a WebDriver that crawls pages and lints widgets for ARIA properties to make sure they're actual reference/working widgets, to some extent. The second is a Orca test for the widgets page, which would basically mean implementing something like https://github.com/GNOME/orca/blob/master/test/keystrokes/firefox/line_nav_hidden_float.py In the end, the best tools are the ones that people will use, so it's really up to the Gitea developers to give input on what would build in to their workflow and how to handle a refactor. Starting with just dropdowns would be a decent exercise for this. The main busywork comes from fixing up the HTML to use specific widgets. The actual game plan for this involves creating widgets that are mappable to ARIA widgets, and code that adds ARIA support code for them. Ideally this would build on top of Fomantic's components as some kind of glue to make widgets, so instead of a 'dropdown' component used in various places, you'd have high level widgets like 'listbox'. How this gets written and made varies depending on whether you want this to end up as part of Fomantic and maintain that, or just as some template code in Gitea. Maybe it could go in another package altogether? I don't know. The process would probably go like this: - Go through all the Gitea pages and identify what types of widgets you have and what they do - Figure out a mapping between those and some high-level widgets you'd make that support ARIA - Identify and replace Fomantic widgets with ARIA-aware widgets incrementally

GiteaMirror commented

@lubber-de commented on GitHub (Aug 7, 2021):

As a summary of what's generally working:

Modal dialogs let you tab through background elements still

Modal dialogs don't speak

I started implementing accessibility features to Fomantic-UI.
Modal is currently covered by https://github.com/fomantic/Fomantic-UI/pull/2036

@lubber-de commented on GitHub (Aug 7, 2021): > As a summary of what's generally working: > > * Modal dialogs let you tab through background elements still > * Modal dialogs don't speak I started implementing accessibility features to Fomantic-UI. Modal is currently covered by https://github.com/fomantic/Fomantic-UI/pull/2036

GiteaMirror commented

@techknowlogick commented on GitHub (Aug 8, 2021):

Thanks everyone for participation in this thread. I'm going to close this specific issue thread now, not because I believe everything to be solved but rather once we have an audit completed we can create individual issues for remediation.

We are still seeking out someone to complete an audit (they would of course be compensated for their time) and have reached out to some professionals already, however if anyone has any leads on where we could get an audit please let us know.

@techknowlogick commented on GitHub (Aug 8, 2021): Thanks everyone for participation in this thread. I'm going to close this specific issue thread now, not because I believe everything to be solved but rather once we have an audit completed we can create individual issues for remediation. We are still seeking out someone to complete an audit (they would of course be compensated for their time) and have reached out to some professionals already, however if anyone has any leads on where we could get an audit please let us know.

GiteaMirror commented

@Jookia commented on GitHub (Aug 8, 2021):

Can you keep it open until the audit is completed?

On Sun, Aug 08, 2021 at 11:42:19AM -0700, techknowlogick wrote:

Thanks everyone for participation in this thread. I'm going to close this specific issue thread now, not because I believe everything to be solved but rather once we have an audit completed we can create individual issues for remediation.

We are still seeking out someone to complete an audit (they would of course be compensated for their time) and have reached out to some professionals already, however if anyone has any leads on where we could get an audit please let us know.

--
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/7057#issuecomment-894838206

@Jookia commented on GitHub (Aug 8, 2021): Can you keep it open until the audit is completed? On Sun, Aug 08, 2021 at 11:42:19AM -0700, techknowlogick wrote: > Thanks everyone for participation in this thread. I'm going to close this specific issue thread now, not because I believe everything to be solved but rather once we have an audit completed we can create individual issues for remediation. > > We are still seeking out someone to complete an audit (they would of course be compensated for their time) and have reached out to some professionals already, however if anyone has any leads on where we could get an audit please let us know. > > -- > 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/7057#issuecomment-894838206

GiteaMirror commented

@Jookia commented on GitHub (Aug 8, 2021):

What's the point of closing the bug if it's not fixed and there's no immediate issues to point to?

@Jookia commented on GitHub (Aug 8, 2021): What's the point of closing the bug if it's not fixed and there's no immediate issues to point to?

GiteaMirror commented

@Jookia commented on GitHub (Aug 8, 2021):

Is there an issue for an accessibility audit?

@Jookia commented on GitHub (Aug 8, 2021): Is there an issue for an accessibility audit?

GiteaMirror commented