12

Hello, I did a quick accessibility check for kagi.com and found several issues:

  • 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.
  • Once the "Advanced Search" has been pressed, the dropdowns/menus within it are not well implemented. Keyboard users pressing "Tab" go through all the options for each dropdown/menu, which hurts the UX/accessibility. Please refer to the "WAI-ARIA authoring practices" for a proper and WCAG-compliant implementation. This is especially frustrating on the results page, as keyboard (and screen reader) users will struggle getting to the search results, the main goal of this page (even though the skip links help with that, but one shouldn't rely on them alone). Same happens for the "..." button on each search result.
  • The "Lens" Toggle is not correctly implemented. Screen readers announce it as a "link" and don't announce its state.
  • "News" and "Maps" are buttons but should be links instead (they redirect to a different page)
  • Activating "Videos", "Podcasts" etc. buttons does not announce the changes to screen reader users. Those users don't know that something happened on the page.
    The "Domain" button for search results is announced as a link, but it is a button. It does not announce that a modal appears once the button is clicked. Once it is clicked, keyboard users cannot reach the opened domain modal.
  • The "Dismiss" button on the "To set Kagi as your default search engine click here" notification is not accessible to keyboard users.

Those are just some findings from going through the website via a) keyboard only and b) via screen reader. I'm sure there are a lot more problems, but those are the most prominent when doing what Kagi is meant for: searching the web. On Discord, I've heard a claim that Kagi cares about accessibility and that you got it mostly right already. Unfortunately, I have to disagree. As a keyboard-only user (which includes most screen reader users as well), I would not be able to efficiently use Kagi (and parts of it I would not be able to use at all). I hope that you live by your "humanizing the web" motto and give this topic a proper priority.

Kagi should be usable by all people, independent of their environments and circumstances.

    I forgot two important findings:

    • The focus ring around "Search" button on home page is not sufficient.
    • The focus ring for the search query input is missing.

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

      1. Go to any other website, e.g. https://news.ycombinator.com/
      2. Select any non-interactive text in the middle of the page, like the number of points on HN
      3. 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).

        7 days later

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

          @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 replied to this.

            darekkay Thanks for the examples, we will reinvestigate

                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.

                6 months later

                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 replied to this.
                  3 months later

                  (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

                    7 days later

                    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)

                        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

                          a month later

                          Actually I just noticed that the region, 'order by' and those other search options don't have tab boxes yet

                            Also i'm not sure if when you open 'advanced', the tabbing order is supposed to reset or not.

                              No one is typing