Gitea: Gitea accessibility problem

[dingpengyu]

• Gitea version (or commit ref): 1.8.1
• Git version: 2.21.0
• Operating system: windows10-1903

• Database (use [x]):

  • [ ] PostgreSQL
  • [x] MySQL
  • [ ] MSSQL
  • [x] SQLite

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

  • [ ] Yes (provide example URL)
  • [ ] No
  • [x] 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.

[dingpengyu]

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:

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.

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

[dingpengyu]

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

[dingpengyu]

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.

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

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

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

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

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

1. 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: 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]

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

[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 [e-mail] 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.

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

[Jookia]

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.

[zeripath]

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

[zeripath]

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.

[Jookia]

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

[Jookia]

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.

[dingpengyu]

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

[Flameborn]

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 [e-mail] 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.

[ogomez92]

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

[lafriks]

@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

[ogomez92]

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 [e-mail] 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

[dingpengyu]

Discussion of Gitea roadmap

[Jookia]

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

[dingpengyu]

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