Accessibility issues

darekkay

I've noticed a strange focus behavior. To describe it, first see how it should behave:

Go to any other website, e.g. https://news.ycombinator.com/
Select any non-interactive text in the middle of the page, like the number of points on HN
Press tab

What happens is that the next interactive element (here: user name link) after the selected text is being focused.

This doesn't work on Kagi search results page, though. I wanted to check the accessibility of the new Quick Peek functionality (it's great by the way, even with a screen reader!). I've selected an element right before the Quick Peek. But pressing Tab always focuses the first search result. Keeping the focus right only works if one selects an interactive element (like "See more images").

I'm assuming that this behavior is a feature for some other scenario (as the behavior goes against the native browser behavior), but usually messing around with the focus in such a way is not a good idea (as the issue shows).

Vlad

@darekkay This has been completed. Can you check and report any new/remaining issues/possible improvements? Thanks!

darekkay

@Vlad Thanks a lot for looking into this! However, many of the reported issues are not resolved (sorted by subjective priority):

The "Domain" button (...) does not announce that a modal appears once the button is clicked. Once it is clicked, keyboard users cannot reach the opened domain modal.
Dropdown implementation is not accessible (point 4 from the initial bug report).
My separate comment about the focus behavior.
The focus ring for the search query input is missing.
The wrong "link" vs. "button" semantics, see this overview.
Announcing toggles as links, see point 5 from the initial bug report.

There's another problem with autosuggest (Kagi search input, "Search region" input, possibly others). It's not announced to screen reader users that autocomplete options are available, so those users don't know that there's something they could select. Nor is the index of the suggestions (like 1 out of 2) announced when using arrow keys. Please check this example for reference. Use VoiceOver (macOS), Orca (Linux) or NVDA (Windows) to check the difference and test your implementation.

Vlad

darekkay Thanks for the examples, we will reinvestigate

georgee

Hey @darekkay thanks for your detailed report, we appreciate your help.
Not all issues you reported were fixed at this moment. the things we fixed so far are:

There is a hidden, empty link between "Settings" and the settings button (btw, both lead to the same page, which is confusing).
The settings button has no accessible name, hence it is not announced to screen reader users.
The "Advanced Search" button is not accessible to keyboard users.
The "Lens" Toggle is not correctly implemented. Screen readers announce it as a "link" and don't announce its state.
The "Dismiss" button on the "To set Kagi as your default search engine click here" notification is not accessible to keyboard users.
The focus ring around "Search" button on home page is not sufficient.

We are learning more about other issues and we will improve accessibility soon.

Minionslayer

Hi, I'm a new Kagi user. I'm blind, and thus rely on robust keyboard navigation and screen reader support in technology. I just wanted to address some current issues relating to these areas in Kagi Search as of the time of writing. I apologise if this isn't the most appropriate place to post this; I didn't know if it would be better to create a new thread for these issues and prevent thread necromancy or try and consolidate a11y problems in this thread.

In settings, most tickboxes are detected as buttons with no labels by screen readers. This makes it difficult to know the state of switches.
In various places of Kagi, focusing over some buttons with the keyboard on desktop hovers over them, so that they show more information. This means that keyboard users will inadvertently trigger dialogues and such. Examples: settings combo boxes and domain info/kebab menu on search pages.
On desktop, pressing down arrow on the last item of a search result's kebab menu in order to read the description only wraps focus back around to the beginning of the menu for that search result, making it difficult to read description texts.
Favicons and URLs aren't detectable by screen readers; they just skip over the elements, regardless of their relative placement (as customised in appearance settings). I have verified that favicons and URLs display visually.

I'd be very appreciative if these issues could be looked into, in order to improve already pretty good accessibility.

Vlad

Minionslayer We did significant updates to tne UI. Can you please review and let us know if there is further improvement needed?

Thibaultmol

(i'm not in need of accessibility features) but I really hope that they take this seriously and make work of it. Too much tech is not actually accessible

Thibaultmol

Vlad have you checked the various apps/pages using lighthouse's accessibility check? (It's a base check you can do as a dev and see what to do)

Minionslayer

Vlad I'm delighted to report the changes to the UI are amazing. All a11y issues I reported before have been resolved. For my use-case, Kagi now works fantastically, and I'll seriously consider using it in the long term.
The only improvement I can outline at the moment is, I think it would be less ambiguous for screen reader users if inline content consistently had its own heading or landmark (E.G. for quick peeks and quick answers). Quick answers do already have their own landmarks, however most screen reader users don't navigate by landmark, so finding inline content might still be a little cumbersome (hence potentially using a heading instead).
Either way, this is much more of a minor quibble than a serious issue; the work you have done already and the time it took for you to implement improvements has gone above and beyond.

Thank you, from the bottom of my heart