github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 03:27:53 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

a11y is not good #2157

New Issue
Closed
opened 2026-03-22 13:56:39 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-03-22 13:56:39 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).

Original issue by WofWca on 2023-03-25T09:17:00.000Z

Description

I'm not a big expert on accessibility, but one thing I noticed is that keyboard access is pretty bad.

  1. Checkboxes are not focusable, due to display: none:
    fe764a46e9/src/components/input/fancycheckbox.vue (L79-L81)

  2. Some UI is only shown on hover, but not on focus, so you can't see where your focus is, and can't know that there's even such UI if you're using a keyboard exclusively:
    befa6f27bb/src/components/tasks/partials/singleTaskInProject.vue (L364-L374)
    Many such cases. Search for :hover or opacity: 1. Consider adding :focus to :hover selectors.

  3. Some otherwise hidden elements are still focusable
    0ff0d8c5b8/src/components/misc/popup.vue (L46-L51)

  4. Otherwise poor outline of focused elements. "Search" and "Filters" buttons on the project view, active router links:
    befa6f27bb/src/styles/theme/theme.scss (L3-L6)

  5. Not purely keyboard-related, but some icon-buttons have no labels, like the "Notifications" one.

Gecko (Firefox) browser dev tools' "Accessibility" tab can be of great help for a start.

Vikunja Frontend Version

2f009d0b27

Vikunja API Version

v0.20.4+28-6aadaaaffc

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

image

Original issue on Gitea

@kolaente commented on 2023-03-26T14:33:28.000Z:

Yes, a11y is an ongoing effort. We have a few tasks in the backlog about this already. Problem is none of us are a11y experts either, so we tend to fix stuff as we become aware of it.

dpschen commented on 2023-03-27T12:21:15.000Z:

Very good points. As @konrad wrote: we are aware of that is is a problem in general and we do intend to solve this. We do not see accessibility as a second class citizen and do want to implement everything new with a decent accessibility in mind. That said we have a long list of old issues that we have to take care (from which you mentioned a few). I have the plan to create a component library for Vikunja step by step that should improve the situation in many areas siginficantly. In those components I want to use some of headlessuis components combined with some good parts of vueuse and self written composables to help the accessibility.

Some other background here is that we originally relied on bulma a css framework that doesn't have any continuing development. In the meantime we switched to bulma-css-variables that is deprecated and got replaces by bulvar. Coming from this switch we still have some big underlying css scoping problems that are in the css adjustment prio list in my head above 'micro' adjustments like changing hover states etc. This has mostly to do with the scope (in the sense of affected code) that a css framework switch implies and not with the importance of individual issues.

Some progress that we already had is more use of semantic elements in the code e.g. replacing <div> buttons and links with <button type="button"> and <a> elements. Still a lot missing though!

Regarding the individual points you wrote:

  • fancycheckbox.vue: this will be fixed by pr #1800 with 3f3d2c
  • missing focus: Strongly agree!
  • popup: That component should be replaced. I have in mind to create an accessible dialog component, an accessible modal component (related but focus not on accessability: the route modal pr) and accessible text hovers for explanations etc. All of these could profit from positioning help from floating-ui. Accessability might come from headlessui or a11y-dialog. But maybe the <dialog> element is enough today.
  • The referenced line from the theme.scss file is not a mistake but was created by intend. The idea was though to create a hover and focus style for all focusable elements.
  • no labels for buttons: We probably should make the label of a button required and have a flag that visually hides the text and makes it accessible via stuff like aria-label and hover popups.

@konrad:

none of us are a11y experts

I wouldn't label myself as an expert but I guess I could say I have at least some decent knowledge in that area.

@WofWca:
If you want to make some suggestions of individual PRs to address individual problems, I'm happy to assist.

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). _Original issue by WofWca on 2023-03-25T09:17:00.000Z_ ### Description I'm not a big expert on accessibility, but one thing I noticed is that keyboard access is pretty bad. 1. Checkboxes are not focusable, due to `display: none`: https://kolaente.dev/vikunja/frontend/src/commit/fe764a46e931ae79f1651f4a669a8c777e260f16/src/components/input/fancycheckbox.vue#L79-L81 2. Some UI is only shown on hover, but not on focus, so you can't see where your focus is, and can't know that there's even such UI if you're using a keyboard exclusively: https://kolaente.dev/vikunja/frontend/src/commit/befa6f27bb607a57eb8ed49d0152b85cdab4cb95/src/components/tasks/partials/singleTaskInProject.vue#L364-L374 Many such cases. Search for `:hover` or `opacity: 1`. Consider adding `:focus` to `:hover` selectors. 3. Some otherwise hidden elements are still focusable https://kolaente.dev/vikunja/frontend/src/commit/0ff0d8c5b89bd6a8b628ddbe6074f61797b6b9c1/src/components/misc/popup.vue#L46-L51 4. Otherwise poor outline of focused elements. "Search" and "Filters" buttons on the project view, active router links: https://kolaente.dev/vikunja/frontend/src/commit/befa6f27bb607a57eb8ed49d0152b85cdab4cb95/src/styles/theme/theme.scss#L3-L6 5. Not purely keyboard-related, but some icon-buttons have no labels, like the "Notifications" one. Gecko (Firefox) browser dev tools' "Accessibility" tab can be of great help for a start. ### Vikunja Frontend Version 2f009d0b27909b577dc7304861ead0a05c017a93 ### Vikunja API Version v0.20.4+28-6aadaaaffc ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots ![image](/attachments/dd9d0015-c033-4e02-a8f9-0a2d2cd6615d) [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/2032) --- _**@kolaente** commented on 2023-03-26T14:33:28.000Z_: Yes, a11y is an ongoing effort. We have a few tasks in the backlog about this already. Problem is none of us are a11y experts either, so we tend to fix stuff as we become aware of it. --- _**dpschen** commented on 2023-03-27T12:21:15.000Z_: Very good points. As @konrad wrote: we are aware of that is is a problem in general and we do intend to solve this. We do not see accessibility as a second class citizen and do want to implement everything new with a decent accessibility in mind. That said we have a long list of old issues that we have to take care (from which you mentioned a few). I have the plan to create a component library for Vikunja step by step that should improve the situation in many areas siginficantly. In those components I want to use some of [headlessui](https://headlessui.com/)s components combined with some good parts of vueuse and self written composables to help the accessibility. Some other background here is that we originally relied on bulma a css framework that doesn't have any continuing development. In the meantime we switched to bulma-css-variables that is deprecated and got replaces by bulvar. Coming from this switch we still have some _big_ underlying css scoping problems that are in the css adjustment prio list in my head above 'micro' adjustments like changing hover states etc. This has mostly to do with the scope (in the sense of affected code) that a css framework switch implies and not with the importance of individual issues. Some progress that we already had is more use of semantic elements in the code e.g. replacing `<div>` buttons and links with `<button type="button">` and `<a>` elements. Still a lot missing though! Regarding the individual points you wrote: - `fancycheckbox.vue`: this will be fixed by pr [#1800](https://kolaente.dev/vikunja/frontend/pulls/1800) with [3f3d2c](https://kolaente.dev/vikunja/frontend/src/commit/3f3d2c25179ea1149238910a74c783a392e88760/src/components/base/BaseCheckbox.vue#L6) - missing focus: Strongly agree! - popup: That component should be replaced. I have in mind to create an accessible dialog component, an accessible modal component (related but focus not on accessability: [the route modal pr](https://kolaente.dev/vikunja/frontend/pulls/2735)) and accessible text hovers for explanations etc. All of these could profit from positioning help from [floating-ui](https://github.com/floating-ui/floating-ui). Accessability might come from headlessui or [a11y-dialog](https://github.com/KittyGiraudel/a11y-dialog). But maybe the [`<dialog>` element is enough today](https://www.scottohara.me/blog/2023/01/26/use-the-dialog-element.html). - The referenced line from the theme.scss file is not a mistake but was created by intend. The idea was though to create a hover _and_ focus style for all focusable elements. - no labels for buttons: We probably should make the label of a button required and have a flag that visually hides the text and makes it accessible via stuff like `aria-label` and hover popups. @konrad: > none of us are a11y experts I wouldn't label myself as an expert but I guess I could say I have at least some decent knowledge in that area. @WofWca: If you want to make some suggestions of individual PRs to address individual problems, I'm happy to assist.
GiteaMirror added the kind/bug label 2026-03-22 13:56:39 -05:00
GiteaMirror commented 2026-03-22 13:56:41 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jun 24, 2025):

We're still tracking this, but I feel like the original issue has been solved. Please ping if you feel like that's not the case.

@kolaente commented on GitHub (Jun 24, 2025): We're still tracking this, but I feel like the original issue has been solved. Please ping if you feel like that's not the case.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label kind/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#2157
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?