Accessibility: HTML semantic not consistent, hard for screenreader users

[fcnjd]

Hello,
at first, thank you for all your work in this project. It is very appreciated!
Since I am blind I use a screenreader. However, sadly the HTML semantics are not always consistant, so there are some unlabelled buttons and unstructured parts. I'll try to sum it up what I found so far. I'm sorry for not providing a PR since I'm experienced in frontend development, however this project is based on React, which mixes up HTML and Typescript in single files - for me as user of a Braille display, this makes it harder to get familiar with the code, as longer files have to be searched through.

So now what I found:

• When you open the preferences, they appear at the bottom of the whole interface with chats, personas etc. Is this really the intention? Wouldn't it be better to either make that as a modal and hide the other contents, or at least make preferences clearly focusable by e.g. an < h1 > element?
• The button to close preferences or "manage models" is unlabelled
• At a call, the labels of the buttons are written below the buttons, however it would be better to have them as button descriptions themselves. Since often you navigate withouth the virtual cursor, or by hotkeys that just jump from button to button, this text would not be read.
• In the "manage models tab" when navigating through the list, the buttons to select models or to open their options are unlabelled.
• The chats in the chat list should have their corresponding HTML semantics (links, buttons) what they're ment to be, not just div
• The buttons for example to delete a chat are unlabelled.
• The interface would be much easier to navigate if structured properly as HTML: < anv >, < main >, < footer >, chat list as < ul > with listitems in it.
  These are the ideas I have so far. I hope you can consider checking this.

Device and browser: Windows 10, Chrome browser, use both Jaws and NVDA screenreaders

[enricoros]

Thanks for finding and communicating the issues. Apologies for a technology stack does not put accessiblity first. On my side, I'm using a UI library that handles accessibility on a per-component basis, as otherwise it would be harder to implement.

A couple of follow-ups:

• Opening preferences is indeed Overlaying a Modal on top of the whole UI, and the rest of the UI shall not be considered by screenreaders. Do you see all the content and preferences last? Preferences also uses 4 tabs
• how does one label the buttons for "manage models" or "close preferences"? There should also be 2 buttons to close preferences: a "x" on the top-left, and a "close" on the bottom-right. In case of an icon, what's the way to label it?
• You tried the Call feature? Great job, that's very new! I think I know what you mean about the button labels, I believe I can do that.
• Thanks for the advice on Chats on the Chats List
• Thanks for telling me about the nav/main/footer/ul for the chat list

Please follow this bug to see updates, and let me know if there is progress.

[fcnjd]

Thank you for your answer, it's nice to see that you're following the issue. I'll try to answer the given questions:

• I don't get the whole UI and then the preferences, but parts of it remain there, like for example the chat input box, below it preferences start.
• It makes most sense to label the buttons as for what they do. Manage models, as well as the "close" button at the bottom of the preferences you already mentioned, buth of them are already correctly labelled. So the icon "x" would probably for the best also get the label to close preferences.
• The 4 tabs work as expected in the settings. However even if I collapse the "labs" section, preferences like the voice calls are still reachable for the screenreader the same way. I'd recommend marking this section with CSS display: none as this is also considered by screenreaders.
• The call feature is great, it makes the communication with the AI model very easy.
  I am subscribed to this issue, so will receive future notifications and am happy to provide further feedback or testing.

[enricoros]

Hi @fcnjd I started modifying the markup of the application. Now has a nav/header/main/aside.

[enricoros]

Hi @fcnjd, I performed structural changes to the HTML, all live on the main branch. This includes most issues you mentioned, and involved restructuring the markup, adding aria-labels and lots of learning.

Are you able to try out the changes and give your advice on what is missing and how to prioritize?
I want to proceed from the top priority to the lower. Thank you.