a11y is not good #3308
I'm not a big expert on accessibility, but one thing I noticed is that keyboard access is pretty bad.
Checkboxes are not focusable, due to
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:
Many such cases. Search for
opacity: 1. Consider adding
Some otherwise hidden elements are still focusable
Otherwise poor outline of focused elements. "Search" and "Filters" buttons on the project view, active router links:
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
Vikunja API Version
Browser and version
Can you reproduce the bug on the Vikunja demo site?
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.
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-labeland hover popups.
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.
If you want to make some suggestions of individual PRs to address individual problems, I'm happy to assist.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?