Accessibility issues

[2LoS]

The following points indicate some accessibility issues in the homepage and documentation pages.
I'll prepare a pull request to fix them in the following days, but I'd first like to receive some feedback on points that involve color contrast and the DOM structure, since they might require some little changes to the current UI/UX. Other minor fixes will be directly included in the pull request.

Skip navigation

It's always a good idea to add a skip navigation button at the beginning of the document. It can be used to skip the repeated content at the top (e.g. masthead, navigation links) to directly land to the main content. The best way is to make it hidden by default, making it visible to screen when the focus is received. [2.4.1]

Logo

In documentation pages, the link around the logo lacks of the aria-label attribute that indicates it's the "MrDocs Home". Technically, it'd be possible to keep it so, since there's already the inner "Mr.Docs" text node. It's also not a main point of confusion for screen-reader users, since they are used that the first link in the header or navigation bar is the logo. However, it's always better to make it explicit and, as done in the homepage, set the aria-label attribute to the same value. [2.4.4]

Search bar

There's a search bar, which is identified by a common <div>. To make it more accessible, the search role should be communicated to assistive technologies. This can be done either explicitly, adding the role search, or implicitly, using the new <search> tag. [4.1.2]
My advice is to use the new tag, yet adding the role attribute to make the role still clear for browsers that don't support the tag - it was added recently. Moreover, I suggest to remove the empty title in the inner input.

Badge

At the bottom of the page, there's the GitHub badge image. The first issue is that the alternative text (alt) of the image communicates the type of image, instead of its meaning. Indeed, it should show the same text of the image - "Continuous Integration: Passing". [1.1.1]

However, it'd be even better if the same presentation was made using the text alone, instead of an image that just shows a text. [1.4.5]

Copy source code

About the blocks of source code, they have a little button that, when clicked, allow to copy the source code into the clipboard. It correctly provides a title, in which the action of the button is explained - "Copy to clipboard". However, the alternative text (alt) of the inner image just says "Copy icon". This is confusing.

Since the image is just decorative, the best solution is to keep the alternative text empty. [1.1.1]

Also, there's a visually hidden text - "Copied!". It's likely displayed to the user when the button is clicked. The issue is that the text, even if is hidden for sighted users, is always visible to assistive technologies. To remove any contents to both sighted users and screen readers, it should be marked as display: none or visibility: hidden.

Image banner

The banner image is a link. In general, I don't think it be useful. However, it's surely not good for screen-reader users: it's just an image link that doesn't provide any information. The only viable information is the alternative text of the image, which is a generic "MrDocsBanner". [2.4.4]

My adice is to remove the link at all. Also, the image has just a decorative purpose, and therefore it can be hidden from screen readers with an empty alt.

House icon

The breadcrumbs has the icon of a house at the beginning. This is redundant and, considered that it lacks of any textual information to communicate its meaning to screen readers, is also inaccessible. Also, the breadcrumbs is identified as a navigational div (role = "navigation"), but is placed inside another navigation (<nav>), which is in turn inside the main div. This is a lot confusing.

Focus

There's a problem with the visibility of focus in some interactive widgets. Indeed, some inputs, like the search bar, don't show any outline, and others, like dropdown menu, are completely unchanged when they receive the focus. In general, it should be maintained a contrast of 3:1 in the various states (e.g. focus, hover) of interactive components. [1.4.11]

Duplicated navigation

There's a duplicated navigation menu: one has the page-versions class and the other has the components class. I think it's redundant.

Navigation bar

Inside the nav-menu div, here's a list that has only one item, which contains in turn another list. This is useless and quite confusing.