a11y is not good #3308

New Issue

WofWca · 2023-03-25T09:17:00Z

WofWca commented

2023-03-25 09:17:00 +00:00

Description

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 display: none:
fe764a46e9/src/components/input/fancycheckbox.vue (L79-L81)
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.
Some otherwise hidden elements are still focusable
0ff0d8c5b8/src/components/misc/popup.vue (L46-L51)
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)
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

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

image.png

152 KiB

WofWca added the

kind/bug

label 2023-03-25 09:17:00 +00:00

konrad commented

2023-03-26 14:33:28 +00:00

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

2023-03-27 12:21:15 +00:00

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.

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.

👍 2

Sign in to join this conversation.