Issues from Accessibility audit

[Simon-Laux]

We recently got an accessibility quick scan from HAN. They took some time to discuss/test the app with us in a call and gave us a report. treefit and wofwca also made notes during the call, this issues combines points from our notes and the report they gave us. The order is roughly chronological based on the call. (might make sense to reorder and group it into areas of concern, later).

• Hierarchy predictability issue. So user can move logically through the chats. They say we have 3 sections. "accounts", "chats" "messages". From search we need to focus the list of chats
  • 2.4.3 Focus Order
  • Visual sections in the top bar (fix: a11y: improve tab order (navbar) #4672)
  • 2025-05-04: Further improvements, turn the sections into landmarks: fix: a11y: add landmarks #5067
• unread badge says "1", should say "1 new message" (improvement: a11y: aria-label for unread count #4655)
• Text in text avatar should not be read
  • fix: a11y: aria-hidden="true" for some avatars #4661
• Chat nav header (button that opens chat profile) should announce a bit more what it is (like "chat/group with name" instead of just chatname)??
• QR code button should have a link purpose
  • (announce what it does/what it is for, that it opens a dialog)
  • 2.4.4 link purpose in the standard
  • Should say what you'd do with the QR code. The link purpose should be clear to the user.
• QR Code should have a useful alt/label that is not just the filename
  • QR invite fix: a11y: alt text for QR invite image #5038
  • Own secure join group qr code (qr code button)
  • group join code
  • add second device code
• QR dialog: "scan to chat with" should be the header probably
• Gallery: Tabs are not selectable via keyboard (fix: a11y: 'tablist' role for gallery / chat view #4675)
  They use "roving tabindex", which was the case when the audit was performed. Maybe they expected "Tab" to work there. Should we remove roving tabindex?
• Gallery not sure how to escape it. -> wofwca made a tab
  Edit: also see Move gallery to a dialog, instead of it being a tab #5074
• html make use of the <time> tag
  • chatlist
  • message metadata
  • probably also daymarkers?
• padlock and message state
  • group message metadata so it is clear that it is not part of the message
  • don't say padlock, instead say encrypted
  • bigger discussion: think about whether we can omit the padlock (there were discussions also with @r10s whether we should rather show broken lock on unencryped messages)
    2025-04-21 improvement: a11y don't announce "padlock" on msgs #4659 removed the padlock
  • current confusions
    • The "lock" icon on messages. But screen reader should not read the lock. it gives an impression that you can "unlock" the message, like "open it or something". Don't announce it unless it's not encrypted?
    • adb's mum thought it was a handbag 👜
• message metadata contrast is too low in light theme for outgoing messages
  • Green text on the green background, contrast is too low.
• context menus should have better accessibility names
  • the "dialog group" is the name of the context menu.
• can't go back from help
  • idea: close help window with escape key?
  • announce that help window is a new window that will be opened on links to help
  • the help window should stay a separate window and should not become a popup
• footers in dialogs should be part of form / second fieldset - their example was the disappearing messages dialog
  • disappearing messages" dialog says "footer". "save" should be in the form. The buttons should be in a fieldset probably.
• Search - voiceover does not tell that there are results
  • When you enter something to search, it should read out the results.
  • "status message", 4.1.3. Need to implement aria to make this work. ARIA.
• on first open offer to switch to accessible high contrast theme
  • maybe offer as checkbox on the first screen?
  • high contrast theme does not exist yet
  • Maybe pick the most accessible theme by default?
• message list: Reconsider ordered list.
  • Is it a list? not really a list, but
• focus outline/border is not visible enough
  • we need a simple more clear focus outline, maybe look for discord for inspiration, they have a thick blue outline
  • messages
  • chatlist items (especially on selected chats it is not clearly visible)
• Profile hover information is not accessible via keyboard / screen reader (maybe include information via aria attribute into profile?)
• Reactions and Context menu hover buttons on messages are not keyboard accessible
  • also their contrast is way to low to the default background. ("The grey text (#939090) on a light beige (#E6DCD4) background.")
  • note: hover context on messages should hide. Orrr, instead, show it on tab.
• add keyboard shortcuts to change between zoom levels
  • 1.4.4 Resize Text
  • also related is to add another option for font size over rem that is more flexible than zoom levels: Adjust global font size #890

unclear

might need clarification/investigation to be actionable

• Dialogs, close button should be inside of form? legend fieldset

  • The close button is outside the "form" tag. Use fieldset and legend.
  • The QR scan should be a form, even if it's not
  • Wait now they said we should make it not a form.

• What is the situation with context menus how can you trigger them / announce them without mouse?

  • We should have a separate button for context menus? Shift + F10 is not expected by users.
  • how do other apps do this
  • what about menus in other places that don't have the hover buttons? profiles, chatlistitems, images in fullscreen media view, items in gallery, contact list and so on

• new message is not announced

  • fix: a11y: announce new messages of current chat #4692
  • other programs use a statusbar we could have a hidden status bar that we focus on anouncement
  • But when you are in some chat you might not want to be distracted by a busy group? so thats why it is unclear.
  • When you receive a message with window focused, it doesn't announce that you got a new message.
    • It should receive focus, but it doesn't have to be visible.
    • Aria could be implemented, but simply adding an element and giving it focus should work.
  • 2025-04-23 We had a chat in "Delta Chat Dev" and decided that it'd be a good start to add just a "plop" sound for new messages of the current chat, same as on mobile. This way the user is at least notified of a new message, then they can move focus to it to make the screen reader read it.
    Edit: feat: play sound on incoming msg in current chat #5143.
    However, for non-current chat of the current account we still need something else: we don't show notifications for the current account's new messages when the window is in focus.
    2025-05-23 improvement: notify on msg in all non-curr chats #5146 will fix this.

• In the chat, when you get a message, it's also not announced

  • Maybe focusing it will work.
  • but could be annoying if you are reading other messages or writing a message

• Screenreader does not announce that it is successfully sent (aria implementation?)

  • it is a bit unclear as messages that are sent are pending at first then can change their state to failed of sent. even after they are sent they can still change to failed (if there is a could not deliver notification)
  • 2025-04-22 improvement: a11y: aria-live for message status #5021 should address this, somewhat at least.

• encryption info is not interesting in guaranteed e2e encrypted chats, because there are info messages about the chat's state?

  • still if encryption was lost, then you it becomes interessting again, as you don't always want to read the entire chat history looking for the info messages just to find out if your message was encrypted

• But still, the QR should maybe more somewhere else because it related to your own profile

  • that it is more clear that it is about the profile and not the chat.

• "Bypass block"-options are missing that could allow users to navigate the application more efficiently using a keyboard or screen reader. Please consider implementing “skiplinks” in strategic locations. 2.4.1 Bypass blocks

  • They suggested skip links. instead of arrow keys????

General / other:

• Ensure assistive technology notifies users about status changes, particularly for recently changed elements that are not currently in focus. https://www.w3.org/WAI/WCAG22/Understanding/status-messages
• Message list arrow keys is alright.

Other findings:

• To further enhance the application, please review the use of semantic HTML elements. For example, an ordered list is used to structure chats inside the chat pane, which might be suboptimal. Additional suggestions were made during the accessibility audit regarding forms. Please consider using fieldsets and legend tags more consistently throughout. Remove footer tags at the bottom of forms and instead use an additional fieldset element to improve semantics.
• A <time>-element is missing for timestamps, which can cause inconsistent (time-based) announcements.
• The chat menus in the Contact list pane and the Top bar have some inconsistencies in their menu items, despite appearing to serve the same function. The menu in the Contact pane menu has items like Pin chat, Archive chat, Mute notifications etc. The menu in the Top bar has items like Search in Chat, disappearing Messages, Mute notifications etc

useful links:

http://www.w3.org/TR/WCAG22

[r10s]

ftr, scan was done by https://ngi.aimsites.nl/quickscan/

[pvagner]

• what about menus in other places that don't have the hover buttons? profiles, chatlistitems, images in fullscreen media view, items in gallery, contact list and so on

There is aria-haspopup that allows developers and content creators to help screen reader users to identify shift+F10 context sensitive menus and other popups. So when aria-haspopup="menu" is set on a button, on a tab control, on a list item I think it's pretty natural experience to do a thing when pressing the enter key or the space key and popup the menu when pressing F10 key.
Moderate and power screen reader users are often proficient to use keyboard commands of the operating system and their screen reader, so if the popup menu is already there and is keyboard accessible, consider adding aria-haspopup where it makes sense.
From the keyboard using shift+F10 and / or the applications key on the right hand side of the keyboard is a common way on how to access such a popup menu.
With touch screen interaction press and hold gesture is commonly used to access such a popup menu.

"Bypass block"-options are missing that could allow users to navigate the application more efficiently using a keyboard or screen reader. Please consider implementing “skiplinks” in strategic locations. 2.4.1 Bypass blocks

* They suggested skip links. instead of arrow keys????

I'd recommend sticking with logical keyboard navigation i.e. navigating with tab and shift+tab the way you are doing now and keyboard shortcuts e.g. ctrl+m for focusing message input. Skip links are better suited for web portals where the placement of main content may not always be predictable.

Also with that comes another recommendation consider not to move focus as a result of chat state and / or notifications. For example I am chatting in a busy group conversation, I'm trying to type in my message but other group members are exchanging messages and each new message steals my focus from the chat input... That would be complicated.
Also there are desktop notifications and on most platforms screen readers have feature to read these, so I think you don't have to think of making these accessible in other way.
Perhaps it might be doable to set aria-live="polite" on the list where new messages are being appended, however it needs to be well thought and tested as every text insertion contributes to aria-live anouncements. The unpleasant side effect of such an implementation might be that when relative timestamps of existing messages change while I'm starring on a chat log, my screen reader might end up announcing times as these will get rerendered.

Then perhaps consider adding a keyboard shortcuts that will move focus to the chat log similar how ctrl+m focuses chat input. Or perhaps the fact shift+tab moves from chat input to the chat log is enough.

Thanks again for such dedication to screen reader accessibility. If you think it might be usefull to you feel free to get in touch and I'd be happy to try thinking on these and other points you might have from my perspective with you.

Greetings

Peter

[WofWca]

Thank you so much @pvagner, this is really valuable!

[pvagner]

Ah thanks.
Since last time, I have found out you have already experienced live regions within #4692

[WofWca]

Regarding the second audit: I contacted HAN Accessibility Lab again and they said it's OK for them to performed after the Tauri project has ended.