Accessibility issues with the UI

[Chris Henrick]

Hi, this project is really awesome, thanks so much for creating it!

I noticed that there are quite a few accessibility issues with the web UI. The following is a list of things I've noticed while using it. This is likely not a complete list as I did not run any automated a11y tests or do manual a11y testing using various screen reader software which you may want to employ for more thorough testing for a complete list of a11y issues. These were mainly ones I noticed from using the site and poking around the DOM using dev tools.

• there are multiple <h1> tags (in the <header> and in the <main>), there should only be one h1 on the page. I suggest making the one in the main section an <h2>.

• the search box input should be wrapped in a <form> with role="search" or have the text input have type="search".

• the search box does not have a label associated with it, so it lacks an accessible name, thus its purpose will not be clear to users of assistive tech such as screen readers.

• the list of autocomplete results does not appear to be associated with the searchbox via ARIA which means someone using a screen reader will have a difficult or impossible time using them. There are patterns for implementing this such as this one and this one

• the gear icon button does not have an accessible name. This can be added via the aria-label attribute.

• the tooltip / popup on the gear icon next to the search box is only accessible via mouseover. Anything that appears visually via mouseover should also appear via focus. This UI element might be better implemented as a toggle tip (vs. a tooltip) where someone clicks it to reveal it. This would enable a keyboard "click" interaction (via enter or space key) to reveal the popup and place focus within it which would be ideal since it contains form elements that control settings. Alternatively move these form elements out of the tooltip and put them adjacent to the search box so that they're not hidden by a mouseover/focus/click interaction.

• the bulleted list in the <main> area is not structured well (example page). Each bullet point (<li>) is within its own <ul> element, and the code snippet is in a <p> tag outside of the <ul>. This structure doesn't take advantage of unordered lists in HTML and could be improved by wrapping all bullet points in the same <ul> and including the code block within the same <li> as its description. Or use a description list (<dl>) to associate the descriptive text (key <dt>) with the code snippet (value <dd>).

• the UI appears to be created as an SPA and dynamically loads content on the page vs. causing a page reload after searching. If this is the case then consider using a ARIA live region to announce to screen readers that content has been updated on the page when this occurs.

Fixing these issues will help make the project more inclusive and accessible to folks with disabilities, I strongly recommend that they be addressed. Something like one in five people have a disability of some kind, including people who use the CLI, let's not prevent them from benefiting from this project and the knowledge it contains.