Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessibility: Make the individual chat list more accessible. #2141

Open
MarcoZehe opened this issue Feb 20, 2021 · 1 comment · May be fixed by #4294
Open

Accessibility: Make the individual chat list more accessible. #2141

MarcoZehe opened this issue Feb 20, 2021 · 1 comment · May be fixed by #4294
Assignees
Labels
accessibility bug Something isn't working
Milestone

Comments

@MarcoZehe
Copy link

  • Operating System (Linux/Mac/Windows/iOS/Android): All desktop
  • Delta Chat Version: 1.14
  • Expected behavior: The context menu should come up not only on links, but on all chat items, not just by right-clicking.
  • Actual behavior: Context menus only work for focusable elements within each message, if any, like links.
  • Steps to reproduce the problem: Open a chat in DeltaChat and try to open an individual message's context menu without using the mouse.
  • Screenshots: N/A
  • Logs: N/A

Proposed solution

Implement the [listbox]https://www.w3.org/TR/wai-aria-practices-1.1/#Listbox) design pattern, but with a few extras:

  1. The context menu key (shift+F10 on Windows and Linux, the Applications/popup key on Windows, and also a custom implemented Shift+F10 on Mac) should open the context menu on the currently focused item.
  2. Tab should move to focusable items within a message like links. If implemented correctly, this should be handled by the browser engine automatically. The tricky part is if there are multiple links in different messages, one may want to trap the tab key to move to the Attachments button instead of the next link in a different message. Right now, tab just moves through all the links that are anywhere within the current conversation.
  3. Also make the divider items proper list items that can be focused, so users know when they traverse to the next/previous date.
@Simon-Laux Simon-Laux added bug Something isn't working accessibility labels Feb 20, 2021
@Jikstra
Copy link
Contributor

Jikstra commented Mar 3, 2021

@MarcoZehe merci beaucoup for filing all the accessibility issues! I want to focus on fixing them for the 1.16 series. The message list will receive a rewrite and in this process i want to fix this issues :)

@Simon-Laux Simon-Laux added this to the Accessibility milestone Dec 10, 2022
@WofWca WofWca self-assigned this Oct 30, 2024
WofWca added a commit that referenced this issue Oct 30, 2024
Closes #2141

Basically what this commit comes down to:
1. Apply `useRovingTabindex` for message items
2. Set `tabindex="-1"` on all the interactive items
    inside every message that is currently not the active one,
    so that they do no have tab stops.

TODO:
- [ ] Address the TODOs in the code
- [ ] Manage what's gonna be the initially active message,
    because initially they're all active, so
    tabbing to the messages list from the top selects
    the first rendered one as the active one.
    #4292
    could help with this.
    This is also not great for performance: changing `tabindex`
    on a bunch of messages makes them all re-render.
    And otherwise, we probably want to update which one is
    the active one as new messages arrive.
WofWca added a commit that referenced this issue Oct 30, 2024
Closes #2141

Basically what this commit comes down to:
1. Apply `useRovingTabindex` for message items
2. Set `tabindex="-1"` on all the interactive items
    inside every message that is currently not the active one,
    so that they do no have tab stops.

TODO:
- [ ] Address the TODOs in the code
- [ ] Manage what's gonna be the initially active message,
    because initially they're all active, so
    tabbing to the messages list from the top selects
    the first rendered one as the active one.
    #4292
    could help with this.
    This is also not great for performance: changing `tabindex`
    on a bunch of messages makes them all re-render.
    And otherwise, we probably want to update which one is
    the active one as new messages arrive.
- [ ] The interactive items with `onClick` must be actual semantic
    `<button>`s.
    See #4210
    for reference.
@WofWca WofWca linked a pull request Oct 30, 2024 that will close this issue
7 tasks
WofWca added a commit that referenced this issue Oct 30, 2024
Closes #2141

Basically what this commit comes down to:
1. Apply `useRovingTabindex` for message items
2. Set `tabindex="-1"` on all the interactive items
    inside every message that is currently not the active one,
    so that they do no have tab stops.

TODO:
- [ ] Address the TODOs in the code
- [ ] Manage what's gonna be the initially active message,
    because initially they're all active, so
    tabbing to the messages list from the top selects
    the first rendered one as the active one.
    #4292
    could help with this.
    This is also not great for performance: changing `tabindex`
    on a bunch of messages makes them all re-render.
    And otherwise, we probably want to update which one is
    the active one as new messages arrive.
- [ ] The interactive items with `onClick` must be actual semantic
    `<button>`s.
    See #4210
    for reference.
WofWca added a commit that referenced this issue Oct 31, 2024
Closes #2141

Basically what this commit comes down to:
1. Apply `useRovingTabindex` for message items
2. Set `tabindex="-1"` on all the interactive items
    inside every message that is currently not the active one,
    so that they do no have tab stops.
WofWca added a commit that referenced this issue Nov 3, 2024
Closes #2141

Basically what this commit comes down to:
1. Apply `useRovingTabindex` for message items
2. Set `tabindex="-1"` on all the interactive items
    inside every message that is currently not the active one,
    so that they do no have tab stops.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants