gitea: Screenreaders unable to read Gitea's various dropdowns

  • 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

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 3
  • Comments: 91 (58 by maintainers)

Commits related to this issue

Most upvoted comments

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

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.

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

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.

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

Is there an issue for an accessibility audit?

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

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

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

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

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.

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

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 😃