Screenreaders unable to read Gitea's various dropdowns

[dpy013]

• Gitea version (or commit ref): 1.8.1

• Git version: 2.21.0

• Operating system: windows10-1903

• Database (use [x]):

  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite

• Can you reproduce the bug at https://try.gitea.io:

  • Yes (provide example URL)
  • No
  • Not relevant

• Log gist: not needed

Description

Gitea, as with gogs which it was forked from, has many accessibility issues with screen readers including:

1. The dropdown menus are clickables, so many screen readers do not know what to do with them as they do not use the mouse cursor.
2. The license selection/.gitignore selection (and most other menus of that type) are inaccessible, as they all use mouse oriented actions.
3. Possibly others I haven't seen yet.

Unfortunately, this is caused by the toolkit you use, which does not seem interested in making their toolkit accessible. It can be worked around with aria markup, or by changing toolkits (the first of which is easier to begin with but requires more maintenance over time, the second of which is of course much harder, but once you get it done it's done pretty much forever).

See the original issue on gogs for more info: gogs/gogs#3340

Looking forward to seeing if anything can be done about this.
-dingpengyu.
tests screen reader: NVDA
thank

[lunny]

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

[dpy013]

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?

[xogium]

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...

[lafriks]

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 :)

[Jookia]

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

Semantic-Org/Semantic-UI#348
gogs/gogs#3340
#1263

and mine from yesterday: #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.

[zeripath]

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]

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.

[Jookia]

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?

[zeripath]

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

[Jookia]

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.

[dpy013]

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]

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

[zeripath]

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

[Jookia]

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]

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.

[xogium]

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.

[Jookia]

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.

[guillep2k]

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.

[Jookia]

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]

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: #8555

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

[Jookia]

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

[Flameborn]

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]

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

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 Inscryb/inscryb-markdown-editor#18. Since this issue deals with accessibility, I'm posting this for future reference.

[Jookia]

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.

[Flameborn]

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 ***@***.***> 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 <#7057?email_source=notifications&email_token=AAHLD4GFQNVGXO6CYUOMCCLQ4V237A5CNFSM4HPYFNC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEILMOGY#issuecomment-571918107>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLD4AW3NYNGRMDQ25LEC3Q4V237ANCNFSM4HPYFNCQ>.

[Jookia]

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]

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.

[zeripath]

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

[charlag]

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.

[techknowlogick]

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).

[charlag]

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.

[Jookia]

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.

[zeripath]

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

[Jookia]

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

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.

[techknowlogick]

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

[Jookia]

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

[lubber-de]

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 fomantic/Fomantic-UI#2036

[techknowlogick]

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.

[Jookia]

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: #7057 (comment)

[Jookia]

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

[Jookia]

Is there an issue for an accessibility audit?

[fnetX]

I agree to close this rather long (and sometimes a little heated) thread and create a new one. I would have done this before closing, also to publicly call for this and collect some necessary resources (link someone to existing issues and comments that might be useful), but don't want to heat this up again.

Who finds the time to open it first wins my appreciation :-)

[Jookia]

Shouldn't you make the thread before closing it? Seems like an easy way to forget about this issue.

[techknowlogick]

Been AFK for a bit, opened issue here: #16660

Do not worry about this issue being forgotten, as my/others inboxes certainly aren't lacking in emails with regards to accessibility.

[Jookia]

Please re-open this until there's a timeline for #16660 and place change the title back to 'Gitea accessibility problem' since the discussion was much wider